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I. INTRODUCTION 



A. BACKGROUND 

AEGIS is a highly sophisticated weapons system designed 
to safeguard a surface fleet against enemy aircraft and 
missiles. An integral part of the system is the SPY-IA 
radar; it feeds its data to a Navy standard AN/YUK-7 
computer . 

The AEGIS weapons system simulation project is an 
ongoing study being conducted at the Naval Postgraduate 
School. Its primary objective is to study the feasibility 
of replacing the present four-processor AN/YUK-7 mainframe 
computer with a multi-microcomputer based architecture. 

The AEGIS weapon system must process in real-time large 
amounts of data concerning target detection and acquisition. 
In order to distribute the data among the many micro- 
computers, high speed data communication means are needed. 
The high speed data transfer can be accomplished by tying 
clusters of MULTIBUS connected micro-computers to each other 
by means of a local area network such as Ethernet. The 10 
megabit per second data transfer rate over a maximum of 2500 
meters of cable makes Ethernet a powerful data 
communications medium which replaces a complex system of 
point to point cables with a single cable. 
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In order to create a useful progran development 
environment for the AEGIS Modeling Project, it is convenient 
to access more powerful processors located outside of the 
micro-computer cluster hut connected to the same Ethernet. 
The UNIX operating system has been popular on mini-computers 
and is becoming much more commonplace on the newer, more 
powerful micro-computers and is thus a natural candidate for 
a remote login from a terminal connected to the micro- 
computer cluster. 

Initial groundwork in the AEGIS project for the 
connection of micro-computers to more powerful processors 
using the Ethernet was conducted by Stotzer [Ref. 1] and 
Netniyom [Ref. 2]. Stotzer, working at the micro-processor 
end, and Netniyom, working at the other end with a VAX 
11/780 VMS operating system, implemented message passing and 
file transfer routines. As VMS did not provide for a remote 
login as an integral part of the operating system, the 
communication terminated at the VAX end in one of the device 
files, thus reouiring one "hard wired” terminal from the 
system. A hoped-for virtual communication therefore became 
in essence a hard wired connection over the Ethernet. 

B. GENERAL DISCUSSION 

The Berkeley d.E version of the UNIX operating system 
(4.2 BSD) in use at the Naval Postgraduate School runs on a 
VAX 11/780 which is connected to an Ethernet. Since this 
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version of UNIX implements networking software facilities, 
device drivers for networking hardware, and a remote login 
capability, the feasibility of remote terminal login over 
Ethernet to a more powerful remote host from a micro- 
computer was inves t iga ted . The extension beyond Stotzer's 
and Netniyom's work was important since many users could 
remotely use the VAX 11/780 over Just one communication 
medium, Ethernet, without using any of the hardwired 
terminal connections to the remote host. The method of 
investigation used was to capture for analysis the Ethernet 
communications between a Sun Workstation, running 4.2 BSD 
UNIX, and a VAX 11/780, also running 4.2 BSD UNIX. 

C. STRUCTURE OF TEE THESIS 

Chapter I presents some background information on the 
AEG-I S project here at the Naval Postgraduate School and 
prior work to facilitate micro-computer communication with 
more capable processors over an Ethernet connection. It 
also discusses the continuing effort to enhance such 
communication by being able to remotely become a terminal to 
a VAX 11/780 from a micro-computer. 

Chapter II will discuss, in a rather general manner, the 
topics of networks, the ARPANET network, and the relation 
between the ISO standards for networks and the manner in 
which the ARPANET is implemented. Information of local area 
networks and Ethernet will also be presented. Some 
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■baclcffround Icnovledge of these areas is necessary since the 
4.2 BSD UNIX systeji implementation of the remote login 
allows logging in over a long haul network and is thus more 
versatile and flexible than if it were implemented for 
logging in over only an Ethernet. 

Chapter III covers specific information on the MULTIBUS 
system, Ethernet controller hoards, and the single hoard 
computers that were ’ utilized in the course of this 
investigati on . 

Chapter IV will discuss the manner in which the two UNIX 
based computers communicate over the Ethernet when remotely 
logging in. It also covers in detail the AR?.\NET protocols: 



Internet Protocol 


(IP) and 


Transmission 


Control 


?rotocol(TCP) , 


the 


UNIX login. 


terminal , 


and 


trailer 


protocols . 












Chapter V 


will 


discuss the 


purpose of 


and 


results 



obtained by the demonstration program. It will also discuss 
several important anomalies that must be avoided should 
there be work continuing from this thesis. 

Chapter VI presents the conclusions of the thesis. 
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II. NETWORKS 



A. NETWORKS: GENERAL DISCUSSION 
!• background 

The A. 2 BSD UNIX implements the remote login in a 
manner that is general enough to enable one to login to a 
remote host cojnputer over a local area network (LAN), a long 
haul network such as the ARPANET, or any combination of the 
two. Thus it would be possible to remotely login from one 
UNIX system to another by using a local area network to a 
node located on a long haul network, thence over the long 
haul network to a remote host that is also running 4.2 BSD 
UNIX. In such a case the remote login request would be 
surrounded by both LAN protocols and long haul network 
protocols, specifically AFuPANET protocols. In order to 
analyze the remote login converse tion between two UNIX 
systems, some basic knowledge of networks is necessary. 

2. definition 

A computer network is an interconn ect i on of 
autonomous computers. The interconnection can be 
accomplished by a variety of means ranging from hardwired 
conections, micro-wave connections, or even satellite 
connections? in fact, some large networks might employ all 
methods of connections at one link or another within the 
network. The computers should be thought of as autonomous 
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in that there is no master/slave relationship between any of 
the computers on the network. 

3* iims of a Network 

The growth of networks over the last decade has 
been spectacular. This drift away from large, centralized 

computer systems is caused by the many economic and 
performance advantages of networking. ?,y using a network, 
all resources (data, programs, processors, etc.) on the 
network are uotentially available to anyone using the 
network regardless of the physical proximity of those 
desired resources. Computing systems can be made much more 
reliable with the utilization of networks since, should one 
part of the system break down, other parts can tazce up the 
load. Thus systems can degrade in capability gracefully 
rather than catastrophically. Since the cost of computers 
has declined dramatically while the cost of communication 
has remained stable, it now makes more sense to do much more 
processing of data locally and then communicating only the 
results to a central location rather than sending all data 
to a central point for all processing needs. In essence, 
the tremendous needs generated by the information age are 
more easily fulfilled by the utilization of networks. 

4. Ne_twprking Terms 

Some definitions of basic networking terms are 
needed before continuing the discussion. Hosts are the 
various machines located on the network which are intended 
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for running user (application) proarans. The specialized 
computers that perform the switching necessary in a network 
are called interface message processors. A link is 
the physical communication medium used to pass data from one 
IMP to the next IMP in the network. A typical session on a 
network might have the user wanting to send a message to 
another person in a distant location. The user would sit 
down at his host computer and generate his message which 
would he communicated to the IMP which actually puts the 
message onto the network link to the destination. The users 
data, assuming it is a short message, would he transmitted 
across the network in a packet, the basic unit of 
information that moves over the network. A packet switched 
network is one in which the packet can very greatly in size 
and a source to destination path need not he established 
before the packet is sent on its way. For instance, two 
packets from the same host to the same destination may leave 
the source host one right after the other hut take a 
different route to the destination host. The first packet 
transmitted from the source host may not he the first to 
arrive at the destination. 

5* M§,ihcik Layers 

Networks, especially long haul networks, are very 
complex and reouire elaborate software to make them run 
effectively. In order to allow for rapidly changing 
technology and protocols, the design of software must he 
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very .'nodular in nature. Also, the explosive growth of 
networks has nade the adoption of standards ty all involved 
of paramount importance. »n effort to simplify production 
of and changes to neworking software hy standardizing the 
modularity of the software is found in the seven layered 
approach as espoused by the International Standards 
Organization (ISO). Figure 2.1 shows the ISO standard layer 
approach to communication from one node to another over a 
network . 

Network communication commences when a user at one node 
interfaces with the top layer, the application layer. This 
layer then communicates with the same layer in the 
destination node by what is called a peer to peer protocol. 
A protocol is a communication convention between equivalent 
layers in the source and destination hosts. This is a 
virtual communication; actually the application layer 
interfaces with and makes use of the services provided by 
the next lower layer, the presentation layer. This layer 
communicates to the presentation layer in the destination 
host by means of the presentation layer peer to peer 
protocol. As before, this is a virtual connection; the 
actual communication by the presention layer is to the next 
lower layer. The actual communication continues down 
through the layers until it reaches layer 1, the physical 
layer. The data to be transferred ends up at the lowest 
level surrounded by various extra bits appended by each 
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layer as the data passes through it. It is from this layer 
that the data is actually moved to another node on the 
network hy some physical link, hardwire, microwave, etc.. 
At the destination node, the data ascends through the 
layers, losing the bits added by the source node layers, 
until it reaches the destination application layer. Each 
layer can be pictured as requesting services from the layer 
beneath it and providing services for the layer above it. 

The importance of this layered concept is that functions 
associated with a network connection can be grouped together 
in independent software modules that handle only the 
functions of one particular layer. Should the peer to peer 
protocols change, then only the one software module 
associated with that layer need be altered. 

of the Layers 

The first of the seven ISO layers is the physical 
layer. Its function is the transmitting of raw bits of data 
over a communication channel. The protocol at this layer 
must ensure that if the source transmits a binary 1, then a 
binary 1 is received at the destination. It accomplishes 

this by handling electrical voltages and electrical pulses, 

\ 

cables, and connectors. The Ethernet physical layer uses 
the protocols known as Carrier Sense Multiple Acces(CSMA)/ 
Collision Detection (CD). 

The function of the data link layer is to take the raw 
transmission provided by the physical layer and transform it 
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into a line that appears, to higher protocols, to he free of 
transmission errors. This layer adds flags to denote the 
beginning and ending of messages, utilizes error checking 
algorithms are utilized, and distinguishes data from flags. 
Also, this layer deals with the problems of acknowledgements 
and of flow control (a fast sender swamping a slow 
receiver) . 

The function of the network layer is to control the 
operation of the subnet, the lower three layers. It 
determines the routing to the destination, prevents 
congestion, and breaks large packets into smaller ones if 
they are too large for a particular link, and handles flow 
control within the network. The network layer may provide 
either latagram service or virtual circuit service. 
Datagram service delivers to the next higher layer the 
messages from the transport layer without ordering the 
messages? each is considered an isolated unit. The virtual 
circuit service presents the transport layer with ordered 
messages. For commercial networks, this layer contains the 
accounting algorithms for the billing of customers. 

The function of the transport layer is to ensure host to 
host error detection and recovery, control the size of 
messages passed to the next lower level (some long messages 
might have to be broken up into shorter length messages), 
multiplex the end user address onto the network, and the 
establishment /release of connections across the network. It 
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also routes incoming messages to the' correct process or 
connections within the host and reassembles messages by 
delivering to the next higher level the parts of messages in 
the correct order, which is not necessarily the order in 
which the messages were received. 

The session layer provides the users interface in the 
network. It provides the establishment of a connection with 
a process on another machine. Once the connection has been 
established, it controls the buffering of data, the data 
transfer, and the graceful or abrupt closure of the 
connection . 

The function of the presentation layer is to negotiate 
the syntax for characters as data, text strings, terminal 
display formats, and so on. This layer would also provide 
for data encryption should that be necessary. 

The function of the application layer is largely 
determined by the user. It can provide for such functions 
as login procedures and passwords. Here the type of service 
to the user is defined; i.e., is the transaction a file 
transfer, data transfer, remote login, financial 
transac tion , etc . . 

B. THE ARPANET 

1. lickground 

The Department of Defense started the funding of 
research into computer networks during the 1960's. Through 
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the Defense Advanced Research Projects Agency, money vas 
provided to selected universities and private firms to set 
up an experimental four node network. It became operational 
in 1969. It has since expanded to over 100 nodes that span 
the globe. Because of the length of time it has been in 
existence, the monies provided for continuing research, and 
the sponsorship by a powerful backer, the ARPANET is the 
most significant network in the world. Much of the current 
day knowledge about networks can be traced to the ARPANET 
development . 

2* 4E2ANET Layers 

The networking layers of the ARPANET do not 
correspond in a one-to-one manner with those of the ISO 
standards. Pigure 2.2 shows the ARPANET layers and their 
relation to the ISO standard layers. The ARPANET protocols 
are grouped into four major categories: network backbone, 
network access, host to host, and application or service 
protocols. Each of these is independent and optimized for 
its special function and may contain several protocols 
embedded . 

The network backbone protocols are the IMP-IMP 
protocols, routing protocols, and end-end protocols, network 
access protocols define the interface between a host 
computer and the switching nodes ( IMP 's ) . 

The above protocols are interface protocols between 
imp's and the host computer. They permit reliable data 
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transfer into or out of the IMP to the host linh or 



subnetwork. These two protocols do not, however, provide 
reliable host to host peer communication across the network. 
This all important function is provided by the ARPANET 
internet protocol and transmission control protocol, IP/TCP. 
The protocols will be discussed in depth later in this 
thesis; they form the major part of the communications 
format that takes place in the remote login facility of 4.2 
BSD UNIX. A less robust host to host protocol can be formed 
by combining the same internet protocol with the User 
Datagram Protocol, UDP. This protocol provides a procedure 
for application programs to send messages to other programs 
with a minimum of protocol mechanism. It is transaction 
oriented, and delivery and duplicate protection are not 
guaranteed. Applications that reauire an ordered delivery 
of streams of data should use the TCP vice the UDP protocol. 

Above these layers in the APPANET model are the 
application or service layers and protocols such as telnet 
(the virtual terminal protocol), ftp (file transfer 
protocol), sftp (simple file transfer protocol), etc.. 
Figure 2.3 shows the ARPANET protocol relationships. 

C. LOCAL AREA NETWORKS 

A local area network is best defined by listing 
some of the requirements that are generally accepted as 
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teing necessary in a local area network. It is a collection 
of automonous computers and other resources that: 

a. geographically are within about 2500 meters of one 
another; 

h. have a relatively high bandwidth, usually 

ranging from 1 to 10 million bits per second; 

c. low cost; 

d. capability to support up to several hundred 
connections of devices on the network; 

e. low error rates, high reliability, and independence 
from a centralised control; 

f. ease of installation and extensibility; 



TELNET 



FT? 



TCP 



TFT P 



UDP 



INTERNET PROTOCOL 



LOCAL NETWORK PROTOCOL 



Figure 2.3 ARPANET Protocol Hierarchy 



2* Why Local Area Networks 

There are several reasons for the high interest in 
local area networks. Organizations today may have many 
computers and peripherals located within the same or 
adjacent buildings. Cost and performance considerations 
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demand that most if not all of these devices he tied 



together over some communication medium. The most efficient 
manner of interconnection, rather than a maze of "hardwired" 
connections, is a local area network utilizing a high 
bandwidth physical cable. Each computer or peripheral is 
then attached to the channel over a very short physical 
connection, a distinct advantage of a local area network is 
its ability to more effectively and efficiently perform 
distributed computing tasks. This allows specific functions 
such as file storage, data base management, terminal 
handling and so on to be assigned to specific machines thus 
simplifying implementation. 

Local area networks have several factors that make 
their implementation much easier than long haul networks. 
The routing algorithms can be as simple as broadcasting all 
messages. The routing algorithms on long haul networks can 
become extremely complex, especially when one network is 
tied into other networks. Local area networks do have 
potential congestion problems, but they are minor compared 
to those that can be encountered on long haul networks. 

Local area networks can sense congestion because they 
sense the state of the broaacast channel before attempting 
to use it. Two of the types of local area networks are the 
carrier sense networks and the ring networks! each type has 
a unique method of sensing the state of the network. The 
carrier sense method, when it has data to send, listens to 
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the channel to see if anyone else is hr oaaca s ti n^: . If the 
channel is busy, the station waits until the channel becomes 
idle. Once it has sensed an idle channel, it transmits all 
or part of its data in a packet. If a collision occurs with 
another unsensed packet, thus corrupting the transmission, 
the station waits a random amount of time and then starts 
the process over again. The ring networks, like the carrier 
sense networks, use twisted cable, coaxial cable, or fiber 
optics as the transmission medium; however, the ring net is 
a series of point to point cables between consecutive 
stations. The basic method of the control of network 
congestion is through a token system. 2ach node wishing to 
transmit must have a ticket or token in order to use the 
network . 



3. Ithernet 

Ethernet is a local area network specification 
developed by Digital Equipment Corporation, Xerox 
Corporation, and Intel Corporation. It is designed for the 
high speed data exchange among computers and other digital 
devices located within a moderately sized geographical area. 
The Ethernet specification pertains to the first two layers 
of the ISO model, the physical and data link layer. It 
provides for a data transmission rate of 1? million bits per 
second over a coaxial cable with a maximum length of 2.8 
kilometers. It supports up to 1024 stations with a topology 
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of a branching non-rooted tree. The lin’< control is 
CSMA/CD . 

l£I02§.l 

a. General 

The Ethernet frame consists of the following 
five fields: the destination address, the source address, 

the type field, the data, and finally the frame check 
seouence. The 64 bit preamble used for receiver 
synchronization is not available to the user. 

b. Destination address 

The six byte destination can be one of three 
types of addresses. It can be the physical address of a 
board; this address is unique to each board inter fa cing on 
the Ethernet; its first three bytes are assigned by Xerox 
and the last three by the board manufacturer. It could also 
be a multicast address; this board can be user programmed to 
contain up to 64 different multicast addresses. All boards 
receive broadcast packets. 

c. Source address 

The physical source of the particular board is 
automatically inserted upon packet transmission. This can 
be circumvented, as will be explained later. 

d. Type field 

The two byte type field contents are not 
specified; the user can use it for whatever purpose he 
desi res . 
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Data field 



e . 

The data field must he a minimum of -16 hytes 
and can he as long as 1500 hytes . Should the user data he 
less than 46 hytes, the unused hytes are stuffed with the 
null hyte. 

f. Frame check sequence 

This is a 32 hit cyclic redundancy check of 
the Ethernet frame from the destination address down to the 
last hyte of data. 
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III. NPS FACILITIES 



A. BACKGROUND 

The system used at the Naval Postgraduate School to 
investigate the viability of the remote login over Ethernet 
was composed of the following components: the AEGIS Project 

multi-user system, a Sun Workstation and a VAX 11/780, both 
running 4.2 BPS UNIX. All components of the system were 
connected by an Ethernet. Figure 3.1 shows an overview of 
the system. The makeup of the AEGIS multi-user system is 
shown in Figure 3.2. Its MULTIBUS backplane contains four 
Intel 86/12 Single Beard Computers, two additional memory 
boards, and an Interlan Ethernet Controller Board. Each 
86/12 SBC is attached to its own terminal. Secondary 

storage for the system is provided by two hard disk drives 
and two floppy disk drives. Some basic knowledge of the 
multi-user system components is necessary for the 

understanding of the programs contained in this thesis. 

E. MULTI-USSR SYSTEM COMPONENTS 

1 Single Board Computer 

The 86/12 SBC contains all the components necessary 
for a computer on a single board; it contains an 8086 16-bit 
microprocessor, 64K bytes of onboard RAM, a serial 
communications interface, a programmable interrupt 
controller, and a programmable timer.. It also contains the 
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MULTIBUS BACKPLANE 




Figure 3.2 MuHl-user System 
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circuitry necessary for the use of the hoard on a MULT I BUS 
system. The hoard is configured so that it can act either 
as a MULTIBUS slave hoard or as a master hoard and can 
accept user provided ROM of up to 32K hytes. All of the 
onboard RAM is accessible to offhoard components if the 
hoard is unstrapped; or, conversely, none of the onboard 
memory can he accessed from offhoard components if the hoard 
is strapped. The ability to allow or disallow access to 
onboard memory (strapping) is a convienent feature of the 
SEC that makes it very useful in multi-processing 
installations. In the AEGIS system, the hoards are strapped 
to ensure that no process running on another hoard 
accidentally contaminates the onboard memory of another 
hoard . 

The 8086 was one of the first commercially available 16- 
hit microprocessors. Figure 3.3 shows the internal structure 
of the 8086. The processor is divided into an execution 
unit, SU, and a bus interface unit, BIU. The EU implements 
a standard single-bus, accumulator based arhitecture and the 
BIU manages all bus communications to the outside world. The 
data and addresses are multi-plexed over the same 16 pins of 
the 40 pin chip. The EIU also implements an instruction 
pipeline in order to speed up the execution in the S0S6. Up 
to six pre-fetched instructions are queued for execution. 
General use registers, the AX, BX, CX, and DX registers, are 
16 hits wide and are either 8 or 16 hit addressable. There 
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are also four word adiressatle registers for indicies and 
pointers, the CS(code segment), the DS(data segment), the 
SS(stack segment), and the ES(eitra segment). These segment 
registers serve as base addresses for addressing 64K tyte 
segments within the 20 bit, one megabyte address space of 
the 8086. In order to effectively address one megabyte, the 
base address, only 16 bits, is left shifted by four bits so 
that when added to the 16 bit offset, the full one megabyte 
address space is available. These segment registers are 
programmable so that any portion of the one megabyte address 
space is available. This enables the addressing of memory 
space which lies outside the 645 of 86/12 SBC onboard RAM. 
This is crucial for the ability to address the memory 
expansion boards and other offboard components as part of a 
process running cn the 86/12 SBC. 

2. ^^einpry Configuration on the MULTIBUS System 

The AEGIS project makes use of a multi user system 
to run a multiprocessing operating system, MCORTEX , which 
is appended tc the CPM-96 operating system that is resident 
on each 86/12 SBC. MCORTEX is loaded from disk directly tc 
onboard memory. CPM-86 has a master and a slave version. 
The master version is loaded from disk to the MULTIBUS 
master 86/12 SBC. The slave version is loaded onto a memory 
expansion board called common memory? copies of this are 
then loaded into slave 86/12 SBC's as needed. This common 
memory belongs to all boards and processes and is the area 
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where MCOETSX places various process syr.chrcriizaii on data. 
The ether memory expansion board, call it the extended 
TPA( transient program area), is available to any 35/12 SBC. 
For the purposes of this thesis, this extended TPA was used 
by the PL/I programs as a portion of the data segment from 
and to which the Direct Memory Access operations for the 
Ethernet Control Board were conducted. Figure 3.4 depicts 
in a linear manner the memory utilization in the AEGIS 
multi-user system. 

3- iii3213 21^§I2.et Controller Board 

a. General 

The Ethernet controller Board is a MULTIBUS 
Ethernet communications controller that together with a 
transceiver implements layers one and two of the ISO network 
layer. It implements fully a protocol that complies with 
the Xerox/Intel/Digital Ethernet specification, version 1.0. 

The board performs data link layer functions by 

formatting user data into frames and performing the CSMA/CD 
sensing. It automatically provides the cyclic redundancy 
code generation (CRC code). The board, when listening to 
the network, recognizes and accepts frames which are 

addressed to the board's physical address, one of its multi- 
cast addresses, or any broadcast frame. 

The controller board performs the physical layer 
functions by transmitting/receiving bit streams at 10 
megabytes per second. It also contains a 16R receive buffer 
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£0 that the host computer car. read the incoming frames or 
packets at its own convenience. 3y buffering, it also 
shields the MULTIBUS from the unpredictable arrival time of 
frames. The NI3010 board has the DMA controller that moves 
packets to/from host memory. The board has control of the 
MULTIBUS during this transfer. Should another board take 
over the MULTIBUS between data transfers, the NI3010 board 
will resume its DMA transfer from the point where it 
surrendered the bus. The board also maintains a small buffer 
2K in length for a storage of data to be transmitted. In 

the programs included herein, the NI3010 performs DMA 
transfers to/from the extended T?A memory board. The NI3310 
board also performs extensive self-diagnostics and can keep 
statistics on the network traffic and errors, 
b. Frame transmission 

The host computer sets up in contiguous memory 
a transmit data area in the extended T?A. When instructed 
by the host, the .MI3010 board commences a DMA transfer of 
this data into its transmit buffer. The board does not 
attempt transmission onto the network until specifically 
told to do so by the host. Once instructed to do so, it 
inserts the source address of the board, computes and 
appends the CRC, and transmits the packet. Should a 
collision occur that prevents transmission, the board will 
automatically attempt to retransmit up to 16 times. Figure 
3.5 shows the format of the transmit data area. 
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c. Frame receptions 

When the MI3010 receives a packet that is 
destined for its host, it informs the host via a hardware 
interrupt. When the host decides it is ready for the packet, 
it signals the board which then prefixes frame status and 
frame length information to the received frame, and then 
performs a DMA transfer of the packet into a host determined 
area of memory. In the AEGIS project, it is transferred to 
the extended TPA portion of memory. Figure 3.6 shows the 
format of a packet that has been transferred to the receive 
data area. 
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IV. Rl^OTS LOGIN PROTOCOLS 
A. UNIX REMOTE LOGIN 

1 ki § Lo&ii 

When a user desires to remotely log into the VAX 
from the Sun Worksation, he executes the UNIX command 
P.LOGIN. The Sun then sends/receives packets over the 
Ethernet to/from the VAX login port. The terminal attached 
to the Sun appears to the user as if it were hardwired 
directly into the VAX. All of the networking 

implementations are transparent to the user. All of the 
normal login messages and terminal queries appear, as does 
the same command line prompt used on the VAX UNIX. All 
special control characters, such as *kill", "delete', etc., 
are exactly as those used on the VAX. Investigating the 
viability of duplicating this process on the AEGIS multiuser 
system is the goal of this thesis. 

2* ?§cket Contents 

The first step taken in investigating the UNIX 
remote login processs was to produce a program for the AEGIS 
project's multiuser system that passively listened in on 
the Ethernet and captured the conversation between the VAX 
and the Sun when remotely logging in and conducting a 
terminal session. The program, LISTEN, captured all traffic 
on the Ethernet and printed it into a file in either 
hexadecimal or binary format. Since the Ethernet cable had 
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only three devices connected to it at the tijie, it was 
possible to eliminate all traffic on the cable except these 
packets that were directly involved with this remote 
login/terminal process. 

Examination of the packets revealed that several 
protocols were present. The most obvious protocol was the 
Ethernet protocol. The only item of interest here as far as 
the remote login was the Ethernet header type fields. As 
mentioned in Chapter II, this field is undefined in the 
Ethernet specifications and is available to the user for 
whatever use he deems appropriate. In this case, the low 
order byte of the type field was always 8 hexadecimal and 
the high order byte was 0. The reason for this is not known 
to the author. 

There were two ARPANET protocols present, the Internet 
and TCP protocols. There were also UNIX login, terminal, 
and trailer protocols. The login and terminal protocols are 
very similar to those used during a normal login session 
when a terminal is hardwired into the VAX UNIX. The 
conversation over the Ethernet can be viewed as protocols 
wrapped in protocols. The Ethernet protocols are the 
outermost layer, then Internet and TCP, then the UNIX 
protocols . 

At first glance it appears that there is a lot of excess 
baggaee used to merely become a terminal over the Ethernet. 
However, the implementation used by A. 2 BSD UNIX is 
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sufficiently general so that the remote login conld take 
place from the Sun, over the Ethernet to the VAX, and then 
over the ARPANET to another node running 4.2 BSD UNIX. A 
much less complex method could have been implemented, hut it 
would not have complied with ARPANET specifications. 
Besides, since there is a large bandwidth available on the 
Ethernet, these extra bytes take up little "space”. 

B. INTERNET PROTOCOL 

1 . Background 

The Internet Protocol (IP) was developed for use in 
packet switched, interconnected networks. The fundamental 
purpose of IP is to transfer data from one host to another 
over a long haul network and to allow long blocks of data to 
be broken up into smaller pieces (fragmentation) should a 
particular link in the network not be able to handle that 
sized block of data. The block of data transferred by I? is 
referred to as a datagram. The IP datagram consists of two 
elements, a header and the actual data. The scope of this 
protocol is limited; it does not provide for end to end 
reliability, flow control, sequencing, or other host to host 
protocols. These later functions are the objects of the next 
higher protocol, TCP. 

Figure 2.2 shows the relation of IP to the other 
ARPANET protocols. The layering indicates that the IP would 
be called upon to provide services for the next hisher 
protocol, TCP, and to call upon the network interface for 
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services reouired by I?, la the remote login process, the 
TCP segmen t ( header and possilly data) is the data portion of 
the IP datagram. IP would then call on an Ethernet device 
driver to transmit the I? datagram. At the receiving host, 
there must be an IP protocol layer that properly interprets 
the header information for its next higher layer. 

When a user wants to send data to a remote station on a 
long haul network, he provides the application layer with 
the name of the desired destination. It is the job of 
layers above IP to map or change that name into a network 
address. IP needs to know the "where" of the destination 
rather than the "who". IP depends upon lower level modules 
to provide the route for its datagram to follow across the 
ne twork . 

2* IP Specification 

Figure 4.1 shows the I? header format. A 
discussion of the fields follows. The version field is four 
bits long and shows the version number used for the 
information contained in this header. The current version 
of IP header is 4. The IHL field, 4 bits, is the length of 
the internet header in 32 bit words and is used to determine 
where the IP data bytes begin in the datagram. The minimum 
length of the I? header is 5. In the remote login process, 
the IHL is always 5 (20 bytes of header). The type of 
service tells how the datagram is to be treated during its 
trip throughout the network (how important is this 
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datagram). The remote login process uses only 00 in this 
field which indicates normal delay, reliability, and 
throughput and routine precedence (as opposed to priority, 
immediate, flash, etc.). The total length field is the 
total byte count of the datagram, header and data. The two 
byte field allows a length of 65,535 bytes, but this is 
impractical for most hosts and networks. All hosts must be 
able to receive datagrams of at least 576 bytes. 

Fragmentation is not really an issue wnen remotely 
logging in over an Ethernet to a host which is attached to 
the same Ethernet. The length of the data field in the 
Ethernet packet, up to 1500 bytes, is quite adequate to 
accomodate the protocols and data that are used in the 
remote login/terminal process. Fragmentation does become an 
issue when the remote login packet must cross long haul 
networks. The next three fields deal with fragmentation. 
The observed packets always had the identification bytes set 
to some host determined unique number associated with a 
particular source-destination pair and protocol for the tire 
the datagram could be alive in the network. That value was 
incremented by 01 hexadecimal with each packet sent by a 
particular host. The flags field was always 00 hexadecimal 
indicating each packet may be fragmented and that this 
particular packet was the last fragment (which matches with 
the identification field increasing by 01 hexadecimal with 
each packet). The fragment offset indicates where in the 
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orisinal iatasra'm this fra,^ment hslonss and thus was 
observed to always be 00 hexadecimal in the remote login 
process . 

The time to live field indicates the maximum time the 
datagram is allowed to remain in the Internet system. Its 
purpose is to cause undeliverable datagrams to be discarded 
and to bound the maximum datagram lifetime. As with 
fragmentation, this field is necessary if the packet must be 
sent over a long haul network. The observed value was 
always 07 hexadecimal. When remotely loging into a host on 
the same Ethernet, this field must contain a value of at 
least 01 hexadecimal because the IP specifies that packets 
with this field reading 00 hexadecimal are to be destroyed. 

The protocol field always reads 06 hexadecimal which 
indicates that the next higher protocol used in the data 
portion of the datagram is TCP. The header checksum is a 
checksum for the IP header only. It provides for high 
reliability in the communications. In the remote login 
process since TCP and its data form the data portion of IP, 
and this is all covered by the TCP checksum, the entire 
communication is covered by a checksum. The official 
wording of the checksum algorithm is ".... the 16 bit one's 
complement of the one's complement sum of all 16 bit words 
in the header. For purposes of computing the checksum, the 
value of the checksum field is zero. ’[Ref. 3] See Appendix 
F of this thesis for further elaboration on the checksum. 



A8 



The source address and destination address fields are 
grouped into three classes, class a, b, or c. The class 
that was obsserved in the remote login process was the class 
c address. The class is not a function of the remote login 
process* it is the address of the Naval ?os trgraduate School 
on the ARPANET. The class c address has three bytes of 
network address and one byte for the local address. The 
network address of the VAX is c0 09 c8 03 hexadecimal, with 
the 03 indicating its local address. The Sun Workstation 
address is c0 09 c3 01 hexadecimal. The list of all valid 
hosts to which a particular UNIX implementation can talk can 
be found in the UNIX file ’/e tc/host s" * the addresses appear 
in decimal form, not hexadecimal. 

C. TRANSMISSION CONTROL PROTOCOL 
1 . lickgrgund 

The Transmission Control Protcol (TCP) was designed 
to be used as a highly reliable host to host protocol 
in packet-switched networks and in interconnected systems of 
such networks. It provides for reliable inter-process 
communication between pairs of processes in host computers. 
The protocol makes few assumptions concerning the 
reliability of the protocols which belong to lower level 
layers. It is designed to operate above a wide spectrum of 
networks be they hardwired, packet switched, or circuit 
swi t ched . 
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Figure 2.2 shows the position of TC? in the AFPi’NIT 
network layers. TCP would be called upon by higher level 
protocols to provide service for then; and TCP would in turn 
call upon Internet for services. Whatever data or control 
bytes cone to it fron a higher layer would be added to the 
TCP header as data and passed to the IP layer. The TCP 
header and its data, if any, is called a segment, and it 
forms the data portion of an IP datagram in the remote login 
process. The destination host must also contain a protocol 
that recoginizes and evaluates the information contained in 
the TCP segment. 

The TC? performs its services to higher protocols by 
providing mechanisms that ensure data transfer, reliability, 
flow control, multiplexing, and connections. TCP allows a 
continuous flow of data to/from each host. In general, a TCP 
would block and forward data at its own convenience, but 
there are certain times when a user must know that the data 
that has been sent to the TCP has been transmitted. This 
user determined transmission of data is called a "push". 
For instance, in the remote login/terminal process, the user 
forces or "pushes" the transmission of his UNIX command by 
the use of the carriage return key. 

TCP can recover from data that is damaged, lost, 
duplicated, or delivered out of order. This is achieved by 
assigning a sequence number to each byte of data 
transmitted, and requiring positive acknowledgemen t cf 
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reception from the receiving TC?. If not acknowledged, the 
segment is retransmitted after a certain time interval. 
These seauence numbers also allow the receiving host to 
order incoming packets so that they are provided to the next 
higher layer in the proper order. Damaged packets are 
handled by adding a checksum for the TCP segment; damaged 
packets are not processed. TCP is extremely robust. It 
provides recovery from any communications errors, providing 
the TCP is itself functioning. 

TCP handles the problem of a fast sender swamping a slow 
receiver, flow control, by use of the window field. The 
window on an incoming segment indicates an allowed number of 
bytes that the receiver may transmit before receiving 
further permission. The window governs not how many packets 
are sent per unit of time, but how much data can be sent at 
any given time. 

TCP allows for many processes within a single host to be 
communicating with the same remote host simultaneously by 
providing a set of addresses within each host called ports. 
This port address, when concatenated with a network and host 
address form what the ARPANET terms a socket. A pair of 
sockets, one in each host, uniquely identifies what is 
termed a connection. A connection is the process to process 
service provided by TCP. In the remote login process, each 
successful login to the remote host would form a separate 
connection from the user to the remote login port of the 



51 



VAI. Since the login process itself handles many users, 
many user could log in over the Ethernet to the remote login 
port. This can he demonstrated hy using the Sun Workstation 
to log into the 7AX system, then, using that connection, to 
remotley log hack into the Sun, in turn using this new 
connection to remotely log into the VA.X again, and so on. 
Since connections must he established hetveen unreliable 
hosts over unreliable networks, a handshake mechanism with a 
clock-based sequence number intialization is used to prevent 
erroneous initialization of connections. 

2. TCP Specification 

TCP segments (header and data) are sent as part of 
an I? datagram* the TCP header immediately follows the IP 
header. Figure 4.2 shows the format for the TCP header. An 
explanation of the fields now follows. 

The source port and destination port fieleds are used by 
TCP so that it may uniquely identify separate streams of 
data. This address, along with the address fields from the 
IP header form the address of the lata stream that uniquely 
identifies it throughout the network. The port address for 
the UNIX login port is 02 01 hexadecimal (513 decimal); a 
listing of this port address and all network services port 
addresses can be found in the UNIX file "/etc/services". 
UNIX evaluates all source uorts of inbound packets to see if 
they are between 0 to 03 ff hexadecimal. Thus in the 
initial login request from the Sun Workstation, the source 
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port is 03 ff hexadecimal ani the destination port is 22 01 
hexadecimal. Should multiple users desire to lo 2 into the 
VAX from the Sun Workstation, each would use a destination 
port address of 02 01 hexadecimal, but each would use a 
separate source address between 0 and 03 ff hexadecimal. 
This would uniauely identify each TCP connection and hence 
each separate lo^in. 

The sequence number field is a 32 bit number that refers 
to the first data byte in the data portion of that 
particular TCP segment. If there is no data present in the 
TCP segment, such as in the case of acknowledgement only 
packets, then the sequence number refers to the data byte 
that will next be sent by that socket. Since every byte of 
data is assigned a sequence number, the segment seouence 
number is the lowest unused number in the 32 bit sequence 
number space. The acknowledgement number field in a TCP 
segment is the sequence number of the next expected data 
byte of transmission in the reverse direction. Since every 
byte of data has a sequence number, each of them can be 
acknowledged. The simplest form of the acknowledgement 
procedure is to make it cumulative so that an 
acknowledgement number, call it X, indicates that all 
sequence numbers up to, but not including X, have been 
received. The initial seouence number is chosen based on a 
clock based algorithm. This enables TCP to detect duplicate 
packets from a previous Instance of the connection. It is 
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irnpcrtant to note that a pure acknovledfeenent packet does 
not contain data and hence does not occupy sequence nurr'oer 
space. 

The data offset field is the number of 32 bit words in 
the TCP header. The reserved field is reserved for future 
use and is filled with 0's. Each bit in the control field 
informs the TCP of a particular kind of event; each event 
requires different processing depending upon in which state 
the TCP is. More on TCP states will appear later in this 
thesis. The control bits indicate that the urgent or 
acknowledgement fields are significant, that data is to be 
pushed, to reset the connection, synchronize seauence 
numbers, and that no more data is to be sent over this 
particular connection. 

The window field is the number of bytes of data that the 
sender of the segment is willing to accept from the other 
end of the connection. This is based on the size of the 
buffers available in a particular implementation and how 
much data is in each of the buffers at any given time. The 
observed values in the remote login were predominantly 08 00 
hexadecimal, 204S decimal. The window is the mehanism by 
which a fast sender does not swamp a slow receiver. If a 
sender sends data that is more than can be received, that 
data would be discarded, thus adding to the network traffic 
by necessitating retransmission. Sy examining the sequence 
number and window size on an incoming packet, a TCP can 
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deterniine whether or not the nun ter of lytes that it has to 
send can be received at the other end. 

The checksum field uses the same ale;orithm for 
computation as the I? checksum? it covers a psuedo header, 
the TCP header, and the data portion of the segment. The 
pseudo header is a 12 byte header which contains the source 
and destination addresses from the I? header, a zero byte, 
the protocol number'06, which indicates TCP), and the TCP 
length. The length is the length of the TCP header and 
data? it does not count the 12 bytes of pseudo header. 
Should the length be an odd number, then a zero byte is 
appended as padding in order to form the full 16 bit words 
for the checksum algorithm. Figure 4.3 shows the format of 
the pseudo header. 
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Figure 4.3 Pseudo Reader Format 

The urgent pointer field allows the sender to notify the 
receiver that some urgent data follows. The pointer is an 
offset value from the sequence number of the packet with the 
urgent control bit set; it points to the last byte of urgent 
data. In the remote login process, the options fields in 
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the TC? healer are utilized only during; the establishment of 
a TC? connection. The option observed specified the maximum 
segment size as being 1224 bytes. The padding field is used 
only to ensure that the TC? header contains full 32 bit 
words. The padding is the zero byte. 

3. TCP States 

A connection moves through a progression of states 
during its existence. Figure 4.4 is a finite state model of 
the TCP connection states. It should not be considered as a 
complete state diagram; it depicts only a few of the events 
that can cause a state change. The TCP may change states 
based on the events OPEN, CLOSE, SEND, RSCEI7E, and ABORT 
and the control flags that are set in incoming segments. 
The listen state represents waiting for a connection request 
from any remote TC? and port. Syn-sent represents waiting 
for a matching connection request in response to the 
original connection request. The syn-receiyed represents 
the waiting for an acknowledgement of the syn which was sent 
in response to an incoming syn. The established state 
represents an open connection over which data can now be 
sent in either direction. The fin^waityl state represents 
waiting for a termination request or the acknowledgement on 
one that was sent. The finzwaity2 state represents only the 
waiting for a termination request. The closeywait state 
represents waiting for a termination request from the local 
user. The closing state represents the waiting for a 



57 



closed 



> , 

OPEN ' ' i CLOSE 

[ I 

^ ! , 

1 Isten 



I I 

I I 

I ' 




riqure 4.4 TCP State Claqrafr 



58 




connection termination reouest 



acknowledgement 



for 



, ^ P 



remote TCP. The last-ack state represens the wait for an 
acknowledgement of the connection termination request 
previously sent to the remote TCP. The ii!]]§zh§il state 
represents waiting for enough time to pass to make sure 
that the remote TCP has received acknowledgement of its 
connection termination request. 

When a particula’r event -takes place, the TCP response to 
that event depends upon the state of the TCPj the same event 
can cause different TCP reactions. The response to inbound 
packets is very complex; the algorithms covering the proper 
responses are found in Reference 3 . The states of the TCP 
could be lumped together into three, primary states; the 
first state has to do with getting a connection set up from 
one host/port to another, the second concerns the handling 
of inbound/outbound packets once established, and the third 
has to do with terminating the connection. The UNIX command 
METST.^T will show, among other things, the state of each TCP 
connection . 

22&5?ctipn Is tabl i shmen t 

For a connection to move to the established state, 
the two TCP's must synchronize on each other's initial 
sequence numbers. Since the initial sequence number from 
each socket is unique (they are clock generated, but not 
from a network wide clock), this synchronization is 
necessary so that the acknowledgement mechanism can function 
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properly. This synchrcr. ization is signaled by the syn's 
control bit in the TCP header being set. The 
synchronization requires each TCP to send its own uniquely 
determined sequence number and to receive acknowledgement 
that it has been received by the other end of the proposed 
connection. An example of the connection establishment is 
shown in Figure 4.5. The initial TCP from 3 can contain 
both the acknowledgement and the initial sequence numcer 
thus resultins in a total of three packets. This is where 
the exchange get its name of the "three way handshake'. 

The demonstration program in this thesis does follow the 
above synchronization of sequence numbers and produces a 
connection that moves into the "established" state. It does 
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TCP Connection Establishment 



not handle, in a TCP sense, the production of transmission 
packets nor the processing of inbound packets in the 
established state nor for connection termination. The 
algorithms for all event processing are contained in 
Reference 3 . 
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D. UNIX PROTOCOLS 



1 

All of the protocols discussed thus far have been 
very general and can be applied to many networking 
situations. The Ethernet, I?, and TCP protocols do not 
pertain directly to the remote login/terminal process per 
se. They are just as valid for sending mail, transferring 
files, etc, as they are for the remote 1 cgin/terminal . The 
UNIX protocols that will now be discussed are specific to 
the remote login/terminal process. 

2* UNIX Remote Login Protocol 

A description of the remote login protocols can be 
found in the System Maintenance section of Reference 4. The 
servers for the protocols are ?.L0GIND(8C) and RSHD(SC). 
When the UNIX receives a reouest for a remote login over a 
network, it is RLOGIND that is listening at the rlogin port 
for such requests (listen, in the sense of a TCP state 
diagram). Upon receiving a request, RLOGIND along with 
PSHD checks to see if the reauestcr's source port is witnin 
the range 1-1023. They read characters from the socket un 
to the null byte (00 hexadecimal) and interpret them as 
ASCII characters. They check to ensure that the requestor's 
address is one contained in their host's name data base. A 
null terminated user name of at most 16 characters is next 
read and is considered to be the user name for the host 
machine; a second null terminated user name is read and is 
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considered the user najie on the reauestor's machine. Next, 
a null terminated command to the UNIX command shell is 
retrieved. The user name is then checked against the list 
of authorized users. When all the above steps are 
successful, the null byte is returned over the connection to 
the requestor. The connection is now passed on to the 
regular login process for the verification of the password. 

The above steps are those described in the UNIX 
operating system manuals. Observations of the conversation 
over the Ethernet during the remote login process reveal the 
following. A three way handshake, according to TCP, 
etablishes a connection from the Sun Workstation to the 
remote login port of the 7AX system. (A UNIX NETSTAT 
command issued after only the three way handshake packets 
have been transmitted will show that the login port of the 
VAX has a network connection to the foreign address, Sunl. 
The state of the connection will read ’established’.) In 
the next packet, the Sun Workstation then pushes the null 
byte; then a new packet which has the user name as data, 
then the next packet which also has the user name as data, 
then the terminal type/baud rate appears as data to the VAX. 
The Vax will then send "Password” to the Sun Workstation as 
data to be displayed on the Sun terminal. This is the first 
di splayable data that is passed to the Sun Workstation. The 
Sun will now be using the protocol discussed below. 
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UMI? I§r.oin§i Zi£^2.coi 

Terninals connected to a VAX 11/7S0 running 4.2 BSD 
UNIX are full duplex, character at a time connections that 
normally terminate at a communications interface processor. 
When typing at the terminal, each key stroke is sent 
separately to the UNIX; it is returned or "echoed” to the 
terminal so that it can be displayed on the screen. The echo 
is displayed, not the key when struck. It is this echo 
feature that enables the user to type in a password without 
it appearing on the screen. The operating system knows when 
the user is sending a password, so it does not return or 
echo the keystroke to the terminal. When using the remote 
terminal feature of the UNIX, the remote terminal is treated 
in the same manner as described above. The remote terminal 
process transmits each keystroke as a single packet; the 
provider of the service replies with a single packet that 
echoes the keystroke (this echo is then acknowledged in an 
ack only segment). When the VAX system is sending lines cf 
text to be displayed on the remote terminal, it will send at 
most one line of data in each packet with ASCII carriage 
return and line feed characters as the line terminators. 

?I£i£Cols 

Section 70 of Reference 4 contains information on 
the use of trailing protocols. They appeared after the data 
bytes of the TCP when the length of IP, TCP, and data was 
less than the minimum Ethernet data length of 46. For 



63 



instance, if the remote login/terminal ARPANET pacset was 
only 40 bytes long, there was a 6 byte trailer added to the 
packet to make it a total of 46 bytes long. No 
investigation into the contents of these protocols was 
conducted. 

5. Summary; of Reinote 

Figure 4.6 depicts the protocols that have been 
investigated during the course of this thesis. There would 
be other layers above these, but they were neither 
investigated nor programmed in the demonstration program. 
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Figure 4.6 UNIX Remote Login Protocols 
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V. TEST 0 ? VIAPILITY 



A. DEMONSTRATION PROGRAM 

P§n!22S t rati on Program 

In order to test the viability of a remote login to 
the UNIX over an Ethernet from a CPM based process , a 
demonstration program was' devised that mimicked the remote 
login conversations between the Sun Workstation and the VAX 
UNIX system. The demonstration program used the Sun 
Workstation's Ethernet, ARPANET, and login port addresses. 
The program did not attempt a full implementation of the 
IP/TCP protocols nor of the UNIX remote login/termi nal 
protocols. The goal of the program was to: 

a. establish a TCP connection between the CPM based 
process and the login port of the VAX UNIX machine 
(three way handshake) and 

b. to proceed through the UNIX remote login protocols 
far enough that „the VAX UNIX transmitted the 
request ’Password" (requestor has successfully 
passed through the remote login and has been handed 
off to the standard UNIX login process). 

The successful accomplishment of this could be 
determined through the use of the UNIX command NSTSTAT and 
the examination of the packets that were sent by the VAX 
system in reply to the demonstration program. If the Sun 
Workstation is turned off and then the demonstration program 
is run, executing the command NETSTAT will show that the VAX 
UNIX has a TCP connection "established" to its login port 
from the remote host Sunl. Examination of the packets 
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returned to trie de'nons trat i on program by the VAX UNIX system 
shows acknowledf^ement by the VAX system of all data received 
and the word "Password" passed as the data portion of its 
packets. The demonstration program went no further? the 
user's password was not sent to the VAX, no remote terminal 
protocols nor TCP connection termination protocols were 
attempted. Since, full protocols were not programmed, the 
program assumes that a normal, trouble free remote 
login/terminal sequence will occur. Thus there can not be 
any other packets on the Ethernet not concerned with the 
remote login process. 

Numerous observations of the remote login were obtained 
by the program LISTEN; The three way handshake was observed 
as described in the previous chapter. The demonstration 
program sent out a request for a connection to the VAX UNIX 
login port, waited for the return "syn,ack" from the V.AX, 
then sent an acknowledgement of that packet. When forming 
this acknowledgement packet, the demonstration program, 
DEMO, only processed the inbound packet for its sequence 
number . 

Figure 5.1 illustrates the observed sequence for the 
UNIX remote login protocol. DEMO sent out its packets 
assuming this would be the sequence of events? it pushed the 
four packets, waited for the ack and then null byte from the 
VAX, and then processed the VAX packet for its sequence 
number with which it could form an acknowledgement packet. 
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2* Program! Results 

The demonstration program vas successful in meeting 
its goals. A TC? connection was established and the UNIX 
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Figure 5.1 UNIX Remote Login Seouence 



remote login protocols were successfully negotiated and the 
request passed onto the normal login process of the VAX 
UNIX; the reouestor was asked for his password. 

Significant Program development Anomalies 
During the development of both the demonstration 
program and the LISTEN program, several important anomalies 
developed; one concerned the network protocols, another the 
the NI301P board, and lastly the asynchronous interrupts 
while C?M is executing i/o. 

When DEMO is being used, it initiates a TCP connection 
with the VAX UNIX system in accordance with the 

specifications. However, it does not terminate the 

connection according to the TCP protocol. When DEMO is 
finished, the connection is one sided; the VAX still thinks 
that it has a connection to the Sun. The connection 
eventually times out when the VAX fails to receive any more 
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packets on that connection. The next time the Sun attempts 
a remote login, the 7AX system replies to the initial 
reouest not with an ”ack,syn’ packet hut with a broadcast 
packet. The protocol for this was not investigated, but a 
cursory examination revealed that the intent of the packet 
appeared to be an update to VAX UNIX system address tables 
that were altered when the previous connection from the same 
source terminated abnormally. For further program 
development, this can be avoided by merely logging back into 
the VAX from the Sun before attempting the next running of 
DFr^O. 

When running either LISTEN or DEMO, the program can run 
to normal termination or be terminated early if hung up or 
the desired number of packets has not been received. On 
the AEGIS multiuser system, this can be accomplished by 
either resetting the MULTIBUS cluster or resetting only the 
£6/12 SEC in use. If either program has been terminated 
early by resetting the 86/12 SEC, then the next time either 
one is run an extra byte of data is transferred from the 
board into the extended TPA. When the receive data block is 
overlaid on this portion of memory, it is off by this one 
byte, thus causing the program to improperly determine the 
size of the received packet. This can be avoided by always 
resetting the MULTIBUS cluster before running the program. 
This has the same effect as turning off the power to the 
board and then turning it back on. This power down 
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operation will wipe out all buffers and registers on the 
NI3010 board. Both LISTEN and DEMO will issue a warning 
message when there is a size error and then terminate. 

Pl/I-86 input/output routines are not re-entrant. 
Therefore, when doing any i/o, it is necessary to do so in 
the NI3010 board interrupt handler or make calls through 
this handler. Since the first stem of the board interrupt 
handler is to disable the board interrupts, all code will 
execute to completion without interruption; therefore, no 
i/o routines will be interrupted. If they were, 
unpredictable results on the terminal will occur. 
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VI. CONCLUSIONS 



The goals of the thesis were net by the demonstration 
program's showing the viability of a microcomputer based 
process logging into a VAX UNIX system over the Xthernet. 
The basic information on the protocols used is available; 
they can be implemented on a 16 bit microprocessor; ?L/I is 
sufficiently flexible to allow the linking of the assembly 
language routines necessary to write the device driver for 
the N 13 010 board and to perform 32 bit arithmetic and 16 bit 
checksums . 

Now that the fundamental concepts have been recorded, it 
is necessary to implement, in a modular, layered approach 
the full remote login/terminal capabilities. Cnee 
accomplished, it would be possible to use the program for 
communication over the ARPANET. By logging into the Vax 
UNIX system, its full networking capabilities can be 
utilized. 
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APPENDIX A 
PROGRAMMING NOTES 

There are several features of PL/I-86 and LINK-86 that 
are important to understand so that the programs and linking 
insructions for them can be understood. 

The linking command, for both LISTEN and DEMO are quite 

similar? the only real differences are the assembly lansuase 

modules that are linked into each. The main point to 

understand about them is the parameter listing for the PL/I- 

86 program. The linking commands used were: "link86 

listen[i]” and "linkS6 demo[i]” where the "[i]" option was 

an input file for the linker. The input file was: 

demo [data [abs [8G0] ,m [0] , ad [82] .map [al 1] ] , 
cksum, add32bit .xternasy 

The first parameter for DEMO says to load the data segment 
register of the 8086 microprocessor with 300 hexadecimal. 
This forces the data segment of 64K bytes to run from the 
base address of 8000 hexadecimal to 17fff (remember that 
address registers are left shifted by four bits before the 
offset is added) . Thus one half the data segment is on 
36/12 SBC onboard memory and the other half of the data 
segment is located in the extended TEA. The reason for this 
straddle of onboard/extended memory is that the onboard 
memory is strapped so that it is unaccessible from MULTIBUS. 
Since the NI3010 needs to transfer packets to/from host 
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memory, it must do so to the portion of the data segment 
which is in the extended memory. 

The ’m[0]’ data parameter tells the linker to allocate 
no addi tional memory for the data section of the command 
file. This prevents the overwriting of command file data hy 
the transfer of packets into the extended TPA which lies 
within the data segment address space. 

The ”ad[S2]” data parameter gives the total number of 
additional paragraphs to allocate to the data segment of the 
command file. This enables the user to run either LISTEN or 
DEMO within the local memory of the iSEC 86/12. 

The combination of the linker's loading of the data 
segment register with 800 hexadecimal, the PL/I-86 "unspec ’ 
built in function, and the PL/I-c6 pointer based structures, 
allows the programmer to locate a template in the extended 
TPA for the transmit data blocks and receive data blocks 
for the NI3010 DMA operations. Eor instance, in the LISTEN 
program, the linker has loaded the data segment register 
with 830 hexadecimal, and the receive data block is based on 
a pointer whose value is forced to be 8000 hexadecimal by 
the PL/I-86 statement "unspec'x) = '8000'b4;" Thus the 
address of the receive data block is the sum of the 8000 
hexadecimal and the 800 hexadecimal (left shifted); this 
yields an address of 10000 hexadecimal, which is the first 
byte of the extended TPA. 
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An important point to remember in network 

implementations is that only binary information is received 
or transmitted. The interpretation of each byte of binary 
0's and I's is up to the implementation. A byte could be 
considered to be a character, an integer, or control 
information. For this reason, all declarations of 
structures which are used as overlays for the networking 
packets are declared as ”bit(S)" in PL/I-86. The 

interpretation of these as characters or control is no real 
problem. However, when a particular byte, or more normally 
a group of two bytes, are to be considered as integers, then 
it was necessary to overlay the bit string with a based 
variable whose type was declared as "fixed", "fixed bin(7)', 
or "fixed bin(15)" in PL/-96. This is because run time 
conversions of bit to fixed values caused unexpected 
results . 

Another important point is the manner in which PL/I-S6 
stores integers and hexadecimal values. A two byte integer 
is stored with the least significant byte preceding the 
most significant byte in memory. Thus overlaying a ’fixed" 
or "fixed bin(15)" over the length bytes of the NI3010 
receive frame is acceptable because the protocol says that 
the least significant byte is first in memory followed by 
the most significant byte, just as in PL/I-36. This will 
not work for the length bytes as they are stored for the 
Internet Protocol. There the two byte integer value is 
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Tiost si^nificar. 



transferred into/out of memory with the 
byte first followed by the least significant byte. 
Therefore a two byte PL/I-S6 variable cannot be overlayed on 
the IP length bytes. Similarly, the heiadecimal value 12 34 
i s stored in memory as 34 12. This is important when 
storing 16 bit hexadecimal values in bit(16) variables such 
as the TCP source and destination port addresses. 
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NI3010 DEVICE DRIVE?. ASSEMBLY LANGUA^rS MODULES 
date:20 November 1984: 
author: David J Brewer 

These 3086 Assembly langua^^e modules were developed by 
Brewer for his thesis. [Ref. 5] They are linked into any 
pro? ram that needs to utilize an Interlan NI3010 Ethernet 
Controller Board. They read/write to the various ports of 
the NI3010, initialize the interrupt 5 for the CPU, and 
enable/disable the CPU interrupts. 



XTERNASI 



extrn hi interrupt handler : far 



public write_io_port 
public read_io_port 
public write_bar 

public init ialize_cpu_interrupt s 
public enable_cpu_interrupts 
public disable_cpu_inter rupt s 






wr ite_io_port : 

; Parameter Passing Specification: 

» entry exit 

f 

; parameter 1 <port address> <unchanged> 

f 

; parameter 2 <value to be outputted> <unchanged> 



dseg 

port_address rb 1 
cseg 
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push bx ! push si! push lx! pusn ax 

mov si , [hx] 

mcv al, [si] 

mov port_address, al 

mov si , 2 [bx] 

mov al, [si] 

mov dl, port_address 

mov dh, 00h 

out di, al 

pop ax! pop dx ! pop si! pop bi 
ret 









T* mr* T* T* mr 









read_io_port : 

; Parameter Passing Specification 
> 

i entry exit 

f 

; parameter 1 <port address> <unchanged> 

; parameter 2 <meaningless> <register value> 

cseg 

push bxl push si! push dx! push ax 

mov si, [bx] 

mov al, [si] 

mov por t_addres s , al 

mov si, 2[bx] 

mov dl, port_address 

mov dh, 00h 

in al, dx 

mov [si] , al 

pop ax! pop dx ! pop si! pop bxl 
ret 






> akX* 



writ e_bar : 

; Parameter Passing Specification 
J 

; parameter 1 :the address of the data block to be 
; transmitted or received. 

d seg 
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e_bar_por t 


equ 


0b9h 


h_bar_por t 


equ 


0 hah 


l_har_por t 


ea u 


3hhh 


temp_e_by te 


rb 


1 


temp_es 


rw 


1 


cseg 







; This module computes a 24 hit address from a 32 bit 
; address - actually it's a combination of the SS registe 



f and the IP 


passed via a parameter list 


• 


push hx 


! push ax! push cx! push es! 


push dx ! push si 


mov 


dx, 0600h : common 


memory segment 


mov 


es , dx 




mov 


temp_es, es 




mov 


dx, es 




mov 


si, [hx] 




mov 


ax, [si] 




mov 


cl, 12 




shr 


dx , cl 




mov 


temp_e_hyte, dl 




mov 


dx, temp es 




mov 


cl , 4 




shl 


dx , cl 




add 


ax , dx 




jnc 


no_add 




add_l: inc 


temp_e_hy te 




no_add: out 


l_har_por t , a 1 




mov 


al , ah 




out 


h_har_port , al 




mov 


al, temp_e_hyt® 




out 


e_har_port, al 




pop 


si! pop dx! pop es ! pop cx! 


pop ax! pop hx 


ret 

• 






♦ 

initial! ze_cpu_interrupt s : 




; Module 


Interface Specification: 





Caller: Ethertest(?L/I) Procedure 

Parameters: NONE 
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initmoduls cssg common 
org 114h 

int5_ofiSet rv 1 
int5_segment rv 1 

cseg 
push bx 
push ax 

mov bx , offset interrupt _handler 

mov ax, 0 

push ds 

mov ds, ax 

mov ds ;int5_of f set , bx 

mov bx, cs 

mov ds :int5_segment , bx 

pot) ds 

pop ax 

pop bx 

s ti 

ret 



1 



enable_cpu_interrupts: 

; Module Interface Specification: 

; Caller: Ether te s t ( ?L/I ) Procedure 

i Parameters : NONE 

sti 

ret 



disable_cpu_interrupts: 

; Module Interface Specif ication: 

) Caller: Ethertes t ( PL/I ) Procedure 

; Parameters: none 

cli 

ret 



7S 



> 



in terrupt_handler : 



; IP, CS, and flags are already on stack 
; save all other registers 

push ai 
push hx 
push cx 
push dx 
push si 
push di 
push hp 
push ds 
push es 

call hl_interrupt_handler 

; high level source routine 
J In Ethertest Module (PL/I) 



» restore registers 

pop es 
pop ds 
pop bp 
pop di 
pop si 
pop dx 
pop cx 
pop bx 
pop ax 
sti 
i ret 



end 



79 



APPENDIX C 



LISTING OP LISTEN PROGRA'^ 
listen: procedure options (main); 

/«!!!!!!!!!!!!!!!! I I !!! I ! I ! I !!! I I !!!!!!!!!!!! I !!!!!!!!!!!! ! 

date: 20 novemter 1984 
John Donald Reeke 

This program will capture all packets that are on the 
Ethernet. It does this hy initializing the NI301? hoard to 
the promiscuous mode. The packets are placed one after the 
other in memory starting at S000 hex, the first hyte of the 
extnded tpa . The contents of the packets are output to the 
file PACKET. D.^T hut not to the terminal. The user selects 
either hexadecimal or binary output and also the number of 
packets the program will receive before termination. An 
anomally exits in the NI3010 board. Always hard reset the 
MULTIBUS backplane before using this program. When the 
anomally is present, an extra byte, 0C hex, precedes the 
first packet dma'ed from the board. This causes the receive 
block overlay to be off by this one byte; therefore, the 
size of the first packet is not properly determined by the 
program . 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I !!!! 



declare 



receive data block based( 


re 


c_bi: 


k ptr) 


2 


frame_status 




bit 


13) 


* 


2 


nul l_by t e 




bit 


(s) 


f 


2 


f rame_length_l sb 




bit 


(8) 


f 


2 


frame_length_msb 




bit 


(s) 


9 


2 


des tina tion_address_ 


a 


bit 


(6) 


t 


2 


destination_address_ 




bit 


(S) 


t 


2 


destination_address_ 


c 


bit 


(3) 


9 


2 


destination _address_ 


d 


bit 


(3) 


9 


2 


destination_address~ 


p 


bit 


(3) 


9 


2 


destination_address_ 


f 


bit 


(S) 


9 


2 


source_address_a 




bit 


(0) 


9 


2 


source_add ress_b 




bit 


(8) 


9 


2 


s ource_add ress _c 




bit 


(3) 


9 


2 


source address i 




bit 


(3) 


9 



£0 



2 


source _adire5S_e 


bit 


(S) 


2 


source_addres5_f 


bit 


(3) 


2 


type_f ield_a 


bit 


(3) 


2 


type field b 


bit 


(8) 


2 


data (1500) 


bit (8) , 


2 


crc_msb 


bit 


(8) 


2 


crc_upper_middle_byte 


bit 


(8) 


2 


crc_lowe r_middle_byte 


bit 


(3) 


2 


crc Isb 


bit 


(8) 



size_ptr pointer, 

size fixed bin(15) based (size_ptr), 

fill_xtpa ( 15020 ) char based ( rec_blk_pt r ) , 

output_type char(l), 

user_desires fixed, 

packet file, 

rec_blk_ptr pointer, 

number _of_packets fixed static init(0), 
copy_ie_register bit(8), 
i fixed bin ( 15) , 
reg_value bit (8) , 

border (80) char (1) static initial ((80)'-'), 



/# Modules external to this module */ 



write_io_port entry (bit '?) ,bit (3) ), 
read_io_port entry (bit '.8) ,bit (8) ), 
initialize _cpu_ inter rupts entry, 

enable_cpu_interrupts entry, 

disable_cpu_interrupts entry, 

write_bar entry (pointer); 

/* end module listing */ 



%replace 

next_page by '^1', 

clearscreen by '^z'» 



/'^ codes specific to the Intel 8259a 

Programmable Interrupt Controller (PIC) */ 











icwl_port_ad dress 


by 


'c0 


'b4, 


/« 


note 


that 




icw2_por t_addres s 


by 


'c2 


'b4. 


/« 


icw2 


, icw4: 


t*/ 


icw4_por t_aidres s 


by 


'c2 


'b4. 


/* 


and 


ocw 




ocw_port_address 


by 


'c2 


'b4, 


/# 


use 


same 


«/ 












port 


addr 
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/’*' note: icw 



==> ini t id 1 i za t i or. 
control 
word 



ocw ==> operational 
c ommand 

word / 



cvl i5y '13'b4, 

/* single PIC configuration, edge 
triggered input 

cw2 "by '4?'b4, 

most significant bits of vectoring 
byte? for an interrupt 5, 
the effective address will be 
(icw2 + interrupt ^ ^ which 

will be (40 hex +5) ^ 4 = 

114 hex -/ 



icw4 by'0f'b4, 

automatic end of interrupt 
and buffered mode/master 
ocwl by '9f'b4, 

unmask interrupt 5 I'bit 5) and 
mask all others 

/* end 8259a codes */ 



/* include constants specific to the N I 30 10 
boa rd 

%include 'li st en . del ' ; /- see APPENDIX C ’■V 
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# %l« % 






* 



• |> J,i J,i *^I 5>.t ?|C ?{* ?,* jji 5js sjs y? 



V 



/^- Mam Eody -V 



/* 

disable the ni3010 board so that it does not interrupt 
this new initialization 

*/ 

call write_io_port(interrupt_enable_register , 
disable_ni3010_ interrupt 5 ) ; 



/* 

initialize ni3010, PIC, and CPU interrupts 

«/ 

call read_io_port (co.Tirnand_status_register,reg_value ) l 

call perform_comfT)and(go_of fline) ; 

call perf orrn_command ( res et ) »’ 

call initial! ze_pic; 

call ini t ia li ze_cpu_in ter rupt s ; 

/* 

set the receive block base address at 3000 hex, 
the first memory location in the extended tea; 
fill the extended tpa with 

«/ 

unspec ( rec_blk_ptr ) = '8000^b4; 
do i = 1 to 15000; 

fill_itpa(i) = 

end; 



/* 

user interface 

«/ 

put list (clearscreen) ; 
put skip; 

put edit ((border (i) do i = 1 to 83)) (a); 

put skip list('EMTEE 1 FOR HEX PHI MTOUT : ENTER 2 FOR. BINARY'); 
put skip; 

get li s t ( output_type ) ; 
put skip; 

open file (packet) stream output; 

put skip list('How many packets do you wish to receive'); 
put skip; 

get list(user desires); 
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/- 

pat n 13^12' online and prenare to receive packets 

-/ 

call pe rf 0 rn_c cmmand ( go_onl ine ) ; 
call perform_commani(set_proniscaoas_mode ); 
copy_ie_regis ter = recei ve_block_ava i latle ? 
call write_io_port ( interrupt_enable_register , 

receive_'block_ava liable) ; 



/# 

wait until user specified number of have been packets 
received 

d'o while (number_of_packets < user_desires ); 
end ; 



/* 

reset the ni3010 to clear buffer* close file 

*/ 

call perform_command (reset); 
put skip (3); 

put edit ((border (i) do i = 1 to 30)) (a); 
put skip (2); 
close f iie ( packet ) ; 

/* end main body */ 



» %A» sfp <JU * 

^ 'I' ^ ‘T‘ n* ^ 









/ «*« »V <JU %'« 

This module initailizes the programmable interrupt 
controller on the 86/12 S3C 

^1# ^ % V ^-V OU %V sV • V OU O# / 

-S* nr ^ n^ 'r n^ nr n^ ^ ^ -y* -r *r ^r n' n^ n** ^r -'r ^ nr n^ n** ^ *'r n^ n^ n^ n** n^ n* nr n^ n^ n^ ^r -n^ n* / 



initialize nic: nrocedure; 



declare 

write_io_port entry 
call wri te_io_por t 
call wri te_io_por t 
call wr i te_io_por t 
call wri te_io_por t 

end ini tialize_pic; 



(bit (3) , bit (8)); 
(icwl_port_address,icwl) ; 
( icv2_port_address , icv2 ' ; 
( icw4_por t _addres s , icw4 ) * 
(ocw_por t_address ,ocwl ) ; 
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/ %!«» «J# «k*^ O^ %*.# «JUl «1|^ 0 ^0 ^0 ^0 %*^ %i# *X^ %l^ %.^0 v'« ^*0 ^0 m^*0^\0 «l# %1i# O 0 «*« %*■# 

^|V ^1^ 0^^ ^1^ ^1% ^1% 0^m 0^ ^1% 0y^ ^1% ^1% 0^ «|% 0^ ^1% ^1% #1% #1 % #1^ ^1% 0y^ 4 ^f^ 0^ ■* i^% 0y^ 0^^ 0 0f^ 0 - ^|%#|««>|% «^% #|S 0^'% 0^% 

This 'Tiodule sends to the NI3010 hoard the comTianl received 
in the parameter list. It then waits to see If the command 
has been successfully carried cut hy the hoard. 

V 



perf orm_command r 



procedure (command); 



declare 

command hit (8) , 
reg_value hit (S) , 
srf hit (8) , 

wri te _io_port entry (hit (8) ,hit (8) ), 
read_io_port entry (hit (S) ,hit (8) ); 



srf = '0'h4; 

call write io_port (command regis ter , command ) ; 
do while (Tsrf S. '0l'h4) = ’00'h4); 

call read_io_port (interrupt_status_res, 

srf ) ; 

end; /* do while ’*'/ 

call read_io_port (command_status_register , 
reg_value ) ; 

if (reg_value > '01 ''h4) then 
do; 

/* not (SUCCESS or SUCCESS with Retries) "V 



put skip edit ('*=«==<' ETEERN'ET Board Failure 
( col (35 ) ,a ) ; 



stop ; 
end ; 



5t> 5{C 5,J 



) 



end perfcrm_command; 
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%A^ «*# «JU V^ N*a^ ^'# «/# <k*> W « <k>^ %V ^4f V^ 

^1% ^ -»|% ^p -»p ^p ^p #p y|-» «Pp #p >1^ ^p #'1% ^p y,% ^p ^p ^p ^p ^p ^p pp #p 

This module is called hy the assembly language interrupt 
routine. It handles three NI3010 interrupts: the receive 

block available, receive dma done, and the transmit dma done 



interrupts. It also checks for the NI3010 anomaly and 
prints out an error message and terminates the program 
should the anomaly exist. The receive block is 
repositioned in memory after each packet has been dma'ed to 



memo ry . 

^Af ^ ^ y* ^ 'f* *•■<* ^ v.> V* ^ V' '** y' y* y' V'* y* y* y* y* y* y' y*’ y^ y^ y* ^ ^ y* y^ y« y / 

^ ^1- <T* n* y* 'i- -t* *r* y* *r* on ^ n" •’•' <^ 'I* ■T' mm ^ ■nr '»•* <y ^•r -i' ^ n' y *r np '•r ^ n* ■nr ^r y '»* Jr • r -r mr "r mr ■y ^r ■mr t 'r y nr / 



HL_interrupt _handler ; procedure external? 
declare 



vri te_ic_port entry (bit (8) ,bit (S) ), 
read_io_port entry (bit (S) ,bit (3) ), 
enable_r;pu_interrupts entry, 

disable_cpu_in terrupts entry, 

write_bar entry (pointer)? 



/* 

don't let anything interrupt 
call disable_cpu_int errupts ? 

call write_io_port( inter rupt_enable_register, 

disable_ni3010_interrupts)? 



if ( copy_ie_regis ter = receive_block_available) then 
do? 

call write_bar ( addr ( recei vs_da ta_bl ock y ) ? ^ 
call wri te_io_port ' hi gh_by t e_coun t_r eg , '06 'b4 ) ? 
call write_i o_po r t ( 1 ow_byt e_coun t _reg , '00 'b4 ) ? 

/* initiate receive DMA */ 

copy_ie_regi s t er = recei ve_dma_done ? 

call write_io_portfinterrupt_enable_register, 

receive_dma_done ) ? 

end? /"■■' if receive block available / 
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else 

if ( r opy_i e_re^?i s ter = recei ve_dma_dor.e ) then 
i 0 ; 

number_cf_packets=iiumoer_of_packets e 1» 

si ze_ptr= 

addr(receive_data_block.frame_len«jtb_lsb); 
check for ni301? anomally and, if 
present set number of packets so that 
we drop through to the end of the 
program */ 

if (size > 1522 I size < 64) then 
do I* 

put skip list ('SIZE ERROR'); 
number _of_packet s = user_des i res ; 
end ; 

else 



call print_packet ; 

/* below repositions the receive data 
block overlay */ 
rec_blk_ptr = 

addr ( receive_data_block .da ta ( si ze - 4)); 

If (number_of_packets~)= user_desires ) then 

call write_io_port(interrupt_enable_register, 

disable_ni3010_interrupts ) ; 

else 

do; 

copy_ie_regi s te r = recei ve_block_available ; 
call wri te_io_pcrt ( interrupt_enable_re^ister , 

receiv9_block_ava liable ) ; 

end ; 



end; if receive dma done f 



else 

if (copy_ie_register - t ransmi t_dma_done ) 
then do; 

copy_ie_regi ster = recei ve_block_available ; 
call write_io_port'interrupt_enable_re^ister, 

receive_block_avai lable ) ; 

end; if transmit dma done / 

end HL_interrupt_handler ; 
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This module is ''ailed from the HL interrupt routine. It 
prints each packet received into the file PACKET.DAT. Its 
output is either in hexadecimal or binary, as selected by 



the user. 

^1# 

^1% ^1% •Tf* >P >1^ rj% 






3{c 5{: :}: 5 



^ >■** y 
- -r -r / 



print_packe t : 



procedure ; 



/- 

print out destination , source , frame status, frame 
length, and frame type. 

*/ 

if ( receive_data_hlock .destinatior_address_f = '27^h4) 
then nut file(packet) skip list 

( ' from VAT to SUN' ); 

else if ( recei ve_da ta_hl ock . de s t ina t ion_add ress f = 

'7f"'h4) 

then put file(nacket) skip list 

( ' _ ■ from SUN to VAX') ; 

else put file(packet) skip li st ( 'BHOADCAS T PACKET'); 

put file (packet) skip; 

put file(packet) edit( 'frame status = ', 

receive_data_hlock .frame_status) skip,a,h( 8) ) ; 
put file(packet) skip list 

('frame length = '.size); 

put file(packet) edi t ( 'type_f ield_a = 

receive_data_hlock. type_f ield_a )(skip,a,h(6)); 
put file(packet) edi t( 'type_f ield_h = ', 

receive _data _h lock. type_field_h)( skip, a,h( 3)); 



/■r 

this section prints out the I? and TCP headers 
in either hex or binary 

*/ 

put file(packet) edit('the data is : ' ) ( skip ,a ) ; 
put file (packet) skip; 
do i = 1 to 20; 

put file(packet) skip; 

/* is user selected hexadecimal output *^7 
if (output_type = 'l') then 

put filefpacket) edit('data ',i,'= ', 
receive_data_block .data ( i ) , 'da ta ',(i 20),'= ', 

recei ve_data_block .data ( i + 20)) 
(a,f(4),a,b4(2),col(30),a,f(4),a.b4(2)); 
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else 



put file' packet) edit ('lata ',i,'= 
receive_data_'block .data(i ) , 'data ',(i 2’Z),' 

receive_data_'bl ock .da ta ( i + 20)) 

( a , f '■ 4 ) , a , b (a ) , col ( 30 ) , a , f ( 4 ) , a , t ( £ ) ) ; 

end f 

put file(packet) skip; 



/* 

prints out data portion of TC? in either hex 
or binary 

do i = 41 to (size - 18) ; 
put file(packet) skip; 

/* if user has selected hexadecimal output */ 
if (output_type = 'l') then 
put file(packet) edit('data 

receive _data_b lock. data(i))(a,f(4), a, b4(2)); 

else 

put file(packet) edit('data ',i,'= 

receive _data_b lock. data(i)) (a, f(4), a, b(8)); 

end ; 

put f i le ( na cket ) skip list (next_pa^e); 



end; /* print_packet */ 



end; /* procedure listen */ 
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APPENDIX D 



LISTING 0? DEMONSTRATION PROGRAM 



demo: procedure options 'main); 

/* I !! 1 !! 1 ! 1 1 !!!!!! 1 ! 1 1 !!!!!! I 1 ! 1 !!!!!! 1 !!!! I !!!!!!!!!!!!!!! ! 

date: 20 November 1984: 



author: John Donald ReeKe 

This program demonstrates that a CPM-86 process running on 
the AEGIS multiuser system can remotely login over an 
Ethernet to the VAX 11/780 running 4:. 2 BSD UNIX. It is 
designed to mimic the remote losin of the Sun 'Vor^cstati on to 
the VAX and therefore uses the Sun's Ethernet address, 
source address, and source port. The program is intended to 
only go as far in the remote login process as is necessary 
for the VAX to send the data "Password’ to this process. 
Inbound nackets from the VAX are processed only for their 
sequence number and whether or not they contain data. 

It initializes the ni3010 board and then asks the user how 
many packets to capture before termination of the program. 
Since this program captures all packets on the Ethernet, 
including its own transmissions, a minimum of 22 packets 
should be selected. Next the user is prompted for the 
destination of the remote login. All packe ts received are 
placed consecutively in memory; no contents are displayed to 
the terminal. It is necessary to look in memory with a 
debugging tool such as DDT-S6 to examine the packets. 

Before executing this program, ensure that the VAX and the 
Sun have logged in to each other to preclude broadcast 
packets, as discussed in the body of the thesis, from being 
utilized in the login procedure. Also, the Sun must be 
turned off so that it does not put any packets on the 
Ethernet . 



1 !!!!!!!!!!!!!!!!!!!! 1 !!!!!!!! 1 !!!!!!!!!!!!!!!!!!!!!!!!!!=!' / 



declare 



/* The source address is included in the transmit 
data block because the ni3010 is more efficient 
with the automatic insertion of the source 

suppressed by the "clear insert source address" 
command */ 

1 transmit_data_block based ( trans_blk_ptr ) , 

2 des tination_address_a bit (8), 

2 des tination_adires s_b bit (3), 

2 des tination_address_c bit (3), 



90 



2 


destination_ad dress 


_d bit 


2 


destinaticn_ad dress 


e bit 


2 


destination_aidress 


f bi t 


2 


s ource_address_a 


bi t (6) , 


2 


s ource_address_b 


bit 8 ) , 


2 


source_address_c 


bit f8) , 


2 


sou rce_addre ss_d 


bit ' S) , 


2 


source_address_e 


bit(8) , 


2 


source_address_f 


bit's), 


2 


type_f ield_a 


bit 18) , 


2 


type_f ield_b 


bi t i'8) , 


2 


data (100) 


bit (8) , 



receive data block bas 


ed ( 


r ec 


blk 


?tr ) , 


2 


f rame_sta tus 




bit 


(37 




2 


nul l_byte 




bit 


(8) 


t 


2 


f rame_length_l sb 




bi t 


(8) 

(8) 


t 


2 


f rame_length_'nsb 




bit 




2 


des tination_address 


a 


bit 


(8) 




2 


destination_address 


_b 


bit 


(8) 


• 


2 


des tinatlon_address 


c 


bit 


(8) 


« 


2 


des tination_address 


_d 


bit 


(S) 


t 


2 


destination_ad dress 


e 


bit 


(8) 




2 


des tination_address 


_f 


bit 


(8) 


? 


2 


s ource_address_a 




bit 


(a) 


f 


2 


s ource_addre ss_b 




bit 


(8) 


» 


2 


sour ce_address_c 




bit 


(8) 

(8) 


> 


2 


s ource_address_d 




bit 


t 


2 


source_address_e 




bit 


(8) 


f 


2 


source_address_f 




bit 


(8) 


« 


2 


type_f ield_a 




bit 


(8) 

(8) 


f 


2 


type field b 




bit 


t 


2 


data (15001 




bit 


(8) 


♦ 


2 


crc msb 




bit 


(8) 


1 


2 


crc_upper_middle_byte 


bit 


(3) 


t 


2 


crc lower_middle byte 


bit 


(8) 


t 


2 


crc Isb 




bit 


(8) 


f 



/* how many packets does user want to receive / 
user_desires fixed, 

/* si ze of the Ethernet Packet =^/ 
size_ptr pointer, 

size fixed bin(15) based (size_ptr), 

/* pointers to position overlays in memory '■'/ 

( t rans_b lk_pt r ,rec_blk_ptr) pointer, 

/* number of packets received by this program */ 
number_of _packet s fixed static init(0), 

copy_ie_register bit(8), 
i fixed bin ( 15) , 
reg_value bit (8) , 
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/* Modules external to this -nodule '■'/ 

adi32hit entry ( hi t ( 3 ) , oi t ( £ ) , hi t (S ) ) , 
cksum entry (bit(£), fixed oin(7),bir, (16)), 

wr ite_io_port entry (hit ’3) ,bit (£) ), 
read_io_port entry (bit :'3) ,bit (8) ), 
ini tiali te_cpu_in terrupt s entry , 

enable_cpu_interrupts entry. 

disable_cpu_interrupt5 entry, 

write_bar entry (pointer); 

end external module listing */ 



%replace 

/* codes for programmable PIC on S6/12 S3C*‘ 
note that ic¥2,icw4, and ocw are the same 



icwl_por t_address 


by 


'c0'b4. 


icw2_port_address 


by 


'c2'b4, 


icw4_pcr t_address 


by 


'c2'b4, 


ocw_port_address 


by 


'c2'b4. 



/"' note: lew ==> initialization 

control 

word 

ocw ==> operational 
command 

word */ 



ic wl by '13 'b4 , 

single PIC configuration, edge 
triggered input 

icw2 by '40 'b4, 

/* most significant bits of vectoring 
byte; for an interrupt 5, 
the effective address -vill be 
(icw2 -*■ interrupt #) 4 which 

will be (40 hex +5) * 4 = 

114 hex 

icw4 by '0f'b4, 

/* automatic end of interrupt 
and buffered mode/mas te r / 

' ocwl by '9f 'b4 , 
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/* unmaSiC interrupt 5 (tit 5) and 
xas’rc all otters ' 

/'•' end 3259a codes 



true 


ty 


'1 't . 


false 


ty 


'0 't , 


vai 


ty 


'7f 't4, 


clearscr een 


ty 


Z j 






include constants specific to th 
board and IP/TCP declarations 



%inclnde 'vt.dcl'; 
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QJ 



■nr •'i'* "I'* 'r r'* '•.■* ■'r 'r 'i* *r 



:Ji ‘i\i 



'k' 'r<'i* 'r 



/ 



/■■' Main 3ody -/ 

beeir.J /* initialize the process ^'/ 

del fill_xtpa ( 10000 ) char based ( trans_hlk_pt r ) ; 

/* disable the ni3010 so that it does not 
interrupt this initialization 
copy_ie_register = dis able _ni3010_in te rrupt s ? 
call write_io_port( inter rupt_enable_register, 

disable_ni3010_interrupts) ; 

call read_io_port ( coTirnand_status_register , 

reg_value ) ; 

call perforn_commandigo_offline); 
call ?erform_command( reset ) ) 

/* clear teroiinal, base the trans.nit blocit and 
the receive block in the extended tea, and 
fill the tpa with asteriks . 
put list ' cl ea rscr een ) ; 
uns pec ( t rans _blk_pt r ) = '300l'b4; 
uns pec ( rec_blk_ptr ) = '9600'b4; 
do i = 1 to 10000; 

fill_xtpa(i) = 

end ; 



/'^ initialize the pic 

call wri te_io_port ( icwl_port_addres s , icwl ) ; 
call wri te_io_por t ( icw2_?ort_addres s , icw2 ) ; 
call wr i te_io_port ( ic w4_po rt_add re s s , icw4 ) ; 
call wri te_i o_por t ( ocw_port_addres s , ocwl ) ; 

/’*= end initializing the pic */ 

call initialize_cpu_interrupts ; 
call ini tial ize_header s : 

call perf orrr:_c emmand ( 2 o_online); 

call per f 0 rm_c ommand 'set_promiscuous_mode) ; 

call perform _command(clear_insert_source_address) ; 

/* user interface; perform all of this with the 
board disabled so that the i/o runtime 
routines, which are not re-entrant, will not 
be interrupted. / 

put skip list('how many messages to receive'); 
get list (user_desires ) ; 
call make_ethernet_header ; 

end; end initialization 



94 



/* enable the board for the remote login --/ 
c op y_ie_r egi s t e r = receive_blork_available ; 
call wri te_i o_por t ( interrupt_enable_regi5 ter , 

receive_bloc’£_available) ! 

call remo te_logi n ; 

call per f orm_command (reset); 

/* end main body 



V# O# V# V"^ v«^ 

^ ^ ^ ^ ^ ^,<0 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ «nr*^ ^ ^ -'I' ^r -^r 

This module is called from the main body of this program. 
It initializes the I? and TCP headers, the Ethernet frame 



type filed, and several other variables for use in the 
remote logn. The IP header source and destination addresses 
are the addresses of the VAX and Sun on the AP.PANET. 

*A« Vi ^ Vi ^ v» v^ v.> v^ >y v.» v* v» v« v^ v^ V# v* Vi^ v* %*» v.» V# v., v., ^ v^ v^ v< v,» vl» v> v.» o., v„ y* v.# ■»*■' v» v„ v* v„ *t» i»'< v* »u v.* / 

-o- ^ 'r n* mr ^ ^ ^ mr •n'* n- ^1' m* mm .»,•. ,,1^- m"* ^ mr mm n» **>■* *■.*' ^ -im «*m -t’ n' mr* m' *t* mm mr* -m' m' -r* •'m "m -i' -»t* -i- mm *r '(* / 



initialize headers: 



procedure ; 



/'^ initialize the IP header; some values are 
completely arbitrary in this program; for 
instance, the id_lsb and id_msb */ 



uns psc ( int_hdr_ptr ) = 

internet_header . version_ihl = 
inter net_header.type_of_ser vice 
internet_header.length_msb = 
int er net _header . ler g th_l sb = 
int er net_header . id_msb = 
inter net _header . id_l sb = 
internet_header . flags_f rag = 
inter net_header. t tl = 
inter net_header . protocol = 
internet_header . hdr_checksum = 
internet_header . s our ce_a = 
internet_header . source_b = 
internet_header . source_c = 
inter net_header . source_d = 
inter net_header . dest_a = 
in t er net _header . des t_b = 
internet_header . dest_c = 
internet header. dest d = 



'900f 'b4; 

'45 'b4; 

'00 'b4; 

'00 'b4; 

'2c'c4; 

'23'b4; 

'4e 'b4; 

'0000 'b4; 

'0f 'b4; 

'06'b4; 

'0000'b4; 

'c0 'b4; 

'09 'b4; 

'c3'b4; 

'0l'b4; 

'c0'b4; 

'09'b4; 

'C8'b4; 

'03'b4; 
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initialize the TCP header; sone values are 
completely arbitrary; for instance, th 
seouence number, source pert; h’OTI; th 
source port will he stored in memory 
as 33 ff hex and the destination port 
will he stored as 32 31 hex. '••/ 



uns pec ( tcp_hdr_p t r ) = 
tcp_header . source_port = 
tcp_header .des t_port = 
tcp_header . of f set = 
tcp_header . cor. trol = 
tcp_header .window_msh = 
tcp_h eader . windo v_ls b = 
tcp_header . checksum = 
tcp~h^^<i“r .uraren t_pointer = 
tcp_header .data( 1 ) = 
tcp_header .datal 2 ) = 
tcp_h eader . da t a ( 3 ) = 
tcp_header .data(4) = 
t cp _header . da ta ( 5 ) = 
tcp_header .data( 5) = 
tcp_h eader. seoue nee _num(l)= 
tcp_header . seo uence_num ( 2) = 
tcp~header . sequence~num ( 3 ) = 
tcp_header . sea uence_num ( 4 ) = 



'S323 'b4; 
'ff03'b4; 
'3102 'b4; 
'63'b4; 
syn ; 
'08'b4; 
'30 'b4; 
'3000 'b4; 
'3000 'b4; 
'02'b4; 
'04 'b4; 
'04 'b4; 
'03 'b4; 
'30 'b4; 
'03 'b4; 
'32 'b4; 
'lc'b4; 
'23'b4; 
'01 'b4; 



do i = 1 to 4; 

tcp_header .ack_num ( i ) = '33'b4; 
inc_seq_num ( i ) = '03'b4; 
seg_ack(i) = '00'b4; 

end ; 

seg_len = '00 'b4; 

transmit_data_block . type_field_a = '39'b4; 
transmi t_data_block . type_f ield_b = '33'b4; 



end; /*•■ initialize headers '^ / 
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(D ID 



<^*44 %9^ vO %o %0 ^v %IU V^ ^O «w y^ v^ %v* y« «Jk^ w^ y^ y^ %<^ y# y« y^ y« y^ 

^1% ^1^ ^1% -►*> ^1% >1% «y* #1^ ^1% ^1% r|<* ^y* #^w 

This "nodule is called from various other "nodules. It serds 
to the rii3010 hoard the command received in the parame t e r 
list. It then waits to see if the command was cuccessfully 

carried out hy the hoard. If the command was not 

successful, an error message is displayed and the program 
terminates . 

%y «v y^ vC y^ y< y^ y« y^ y^ yu y.^ y^ y** y^ %o yu y^ y« y^ y^ %v y^ / 

#1% #>1^ -»l^ ^1^ ✓.% ^1% ^1% -*1^ ^1% ^1% ^j% Vp ^1% ^1% •»!% •»!% #1^ / 



perf orm_command : 



procedure (command); 



declare 

command hit (S) , 
reg_value hit (8) , 
s r f hit ( S ) , 

wri te_io_port entry (hit (8) ,hit (3) ), 
read_io_port entry (hit (8) ,hit .(£) ); 



srf = '0'h4; 

call write_io port ( command_regi ster , command ) ; 
do while '(srf 8 '01 'h4) = '00'h4); 

call read io port (interrupt status reg, 

srf); 

end; /* do while */ 

call read_io_port (command_status_register, 

reg value); 

if (reg_value > '01 'h4l then 
do ; 

/* not (SUCCESS or SUCCESS with Retries) ’^Z 

nut skin edit { ETHERNET Board Failure '-5'=^’!=') 
(col(35) ,a) ; 

stop; 

end; /* itd */ 



end per f orm_c ommand ; 
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v«V %V ^ V ^0 

^r* -'i'^ -'r 'i* ^i- '*' *'1' 

This "lodule is 
prornpts ‘.he us 
The Ethernet 
address of the 

V^ 

^1% #P ^1% • 






%l« Vi^ '•*• %*^ 

^;*-r ^i**-,’* ^ -nr 'r ^^-r* 



5 *,^ 



%W %*4 

•'r ^ -Y* ^r ^ ^r *nr o' 



called from the ciain "body of the program. It 
er fcr the destination of the rerote losin. 



address of the Sun is 
Ethernet packet. 



used as 



the source 



/ 



make etheraet header: 



procedure 5 



del 

choice char ( 1 ) ; 



choice = » 

do while (choice 2= '^' ^ choice ~= 'h ' & 
choice ~= 'c' S. choice ~= 'd'); 
put skip list 

('Chose fron helow menu the destination of your pacicet'); 
put skip; 
put skip list 

(' NOTE: enter only lower case letters'); 

put skip; 
put skip edit 

(' a. VAX UNIX',' h. SUNl')(a,skip,a,skip); 
put skin edit 

(' c. MYSELF',' d. MTS') U. skip, a); 
put skip; 

get ed i t ( choice ) ( a ( 1 ) ) ; 
put skip; 
end; /* do while 



if (choice - 'a' 1 choice 
do ; 

transmit_data_’olock 
transmit_da ta_hlock 
transmit_data_hlock 
transmit_data_'blcck 
end ; 
else 
do; 

transmit _da ta_hl ock 
transmit_data_hlock 
transmit_data_'block 
transmit _d a ta_hlock 
transmit_data_‘block 
transmit _d at a_h lock 
e nd ; 



= 'c' I choice = 'd') 

•destination_address_a 
. destination _addres5_'b 
.destination_address_c 
.destination address d 



.destination_address_a 
.destination_address_'b 
.destination_address_c 
.desti nation _addres5_d 
.destination_address_e 
.destination'address f 



then 




'02 


't-i; 


'07 


'h-i; 


'01 


'b4; 


^ rxn 

i- tu 


'o4; 



'02 


'■b4; 


'60 


'h4; 


'3c 


'h4; 


'00 


'd4; 


'42 


'h4; 


'27 


'h4; 
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if choice = 'a' then 
do J 

transnit _d a ta_tloc'^.destinaticn_ad dress _e = '07't4j' 
transnit_^ ata_block . destination_address_f ~ '7f'c4; 
end ; 



else if choice = 'c' then 
do ; 

transnit_data_‘block.destination_addr9ss_e 
transmit~data_'block.destination_address_f 
end ; 

else if choice = 'd' then 
do ; 

transnit_lata_'bloc!£.destination_address_e 

transnit_data_'block.destination_address_f 

end; 



'03 'b4; 
'ea 'b4; 



'04 'b4; 
'0a 'b4; 



transnit_data_block.source_address_a 
transmit _data~block . scurce_address_b 
transmit_data_block.source_address_c 
transmit_data_block.source_address_d 
transmit_iata_block.source_address_e 
transmit data block. source address f 



'02'b4; 
'60'b4; 
'Sc'b4; 
'00 'b4; 
'42'b4; 
'27 'b4; 



end; /* make ethernet header '-V 



^ 

% #1% 



This module is called 
narameter is the number 






%}* 

#1^ .^p #p ^p #p ^p ^p ^p ^p #p ^p ^p 



from the remote_login module. The 
of bytes in the data portion of the 



packet to be transmitted, i.e. the number of bytes in the 
IP/TC? protocols. The parameter is incremented by 14, the 
number of bytes in the Ethernet header of the transmit data 
block. Should the clear insert physical address mode 
change, then it should be incremented by 8 vice 14. The 
parameter passed is a fixed bin'7); it must be overlayed 
with a bit (5) variable sc that it can be written out to the 
board's low byte count register. 

^ w- JU ^ Ou* ^ >js y# y,. •kU / 

>P ^P ^p ^p «p ^p ^p ^p «»p ^p ^p ^p ^p >p ^p 4^^ ^p >p #p ^p ^p ^p ^p >p «»|^ ^ ^p ^ ^ Jp ^p «i^i» ^p «i^% pp ^p >p / 



t ransmi t_packet : procedure ( lcw_byt_cn t ) ; 
declare 

wri te_io_port entry (bit '8) ,bit (3) ), 
read_io_port entry (bit (8) ,bit (3) ), 
enable_cpu_interrupts entry. 



/* used to overlay the fixed bin(7) parameter 
cnt bit(3) based( byt_cnt_ptr) , 
byt_cnt_ptr pointer, 

disatle_cpu_interrupts entry, 

low_byt_cnt fixed bin'7), 
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vrits_oar entry (pointer); 



call di sat 1 e_cpu_in t er rup t s ; 

do while ( c opy_i e_r egi St e r = tran sni t_dma_do ne 

I 

copy_ie_regi ster = recei ve_dma_done ) ; 
call enatle_cpu_iaterrupts ; 

do while ( copy_ie_regi ster = transmi t_dma_dor.e 

I 

I 

copy_ie_register = recei ve_dma_dore ) ; 

end ; 

call di sable_cpu_interrupts ; 

end ; 

copy_ie_regis tei' = di sable_nio010_interrupts ; 
call vrite_io_port (interr up t_enable_ register, 

disable_ni 3010 _interrupts) ; 

call enable_cpu interrupts’ 

call write_bar Taddr ( t ransmi t_da ta_b lock ) ) ; 

call v/rite_io_pcrt(high_byte_count_reg, '00' b4) ; 

/* increment the parameter and overlay it 
low_byt_cnt - low_byt_cnt - 14; 
byt_cnt_ptr = addr ( low_by t_cn t ) ; 
call vrite_ic_port(low_byte_count_reg,cnt ); 

call di sat le_cpu_in t er rupt s ; 

copy_ie_regis ter = transmit_dma_done ; 

call write_io_port(interrupt_enable_register, 

transmi*t_dna_done ) ; 
call enable_c pu_interrupts ; 

do while (copy_ie_register = transmi t_dma_done ) ; 
end; /-■' loop until the interrupt handler 
takes care of the TBr interrupt - 
it sets I5_HS0 to 4 */ 

call perf orm_command ( 1 oad_and_send ) ; 



end transmi t_packet ; 
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% 

^ ^ 






^ %t^ %!-. ^ 



or n' -'r** “ 



* / 



This nodule is called hy the assenoly language interrupt 
routine. It handles three ni3v31? interrupts: the receive 
block available, receive ana done, and the transmit dma 
done interrupts. It also checks for the ni3310 size 
anomally; if found, it prints out an error messsase and 
terminates the program. If a packet is received from the 
VAX, the variable ''seg_ack” is updated so that the outgoirs 
packet's acknowledgement number can be updated in the 
remote_losin module. The variable 'size' is overlaid on the 
frame length of the ethernet packet; it is the length from 
the first destination byte to last CRC byte; it is used to 
reposition the receive _data_block in memory so that no 
portion of th previous packet is overwritten. When 
examining the packets in memory with DDT-S6, each will be 
separaed by the asteriks that were used to fill a large 
portion of the extended tpa. 



* « 



« « 



s ^1% -^5 



V <* ^ 

^1% >1% >1% 



/ 



HL_in terrupt_handler : 



procedure external; 



de cla re 

source bit(8) external, 

wri te_io_port entry (bit (S) ,bit (S) ), 
read_io_port entry (bit (3) , bit(8) ), 
enable_cpu_interrupts entry, 

user_desires fixed external, 
disable_cpu_interrupts entry. 

write_tar entry (pointer); 



call di sable_cpu_interrupts; 

call write_io_port( interrupt_enable_regi s ter , 

disable _ni 30 10_interrupts ); 
if ( copy_ie_register = recei ve_block_avai lable ) 
then do; 

/"• gives address to board for next dma 
of packet into memory */ 

call wri te_bar (addr( recei ve_data_ block) ); 
call w ri te _io_uor t ( hi 2 :h_by t e_coun t _r eg , '06'b4:); 
call write_io_port(low_byte_count_reg, '00 'b4); 

/•'' initiate receive Db'A */ 

copy_ie_register = recei ve_dma_done ; 

call write_io_port(interrupt_enable_reeister, 

recei ve_dma_d one) ; 

end; if receive =block_available ’^V 
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else 



if ( c 0 ■C 7 _ie_rs^i s te r = receive_i7ia_l02e ) ihen 
do; 

nonte r_of _packet 5= nu'nt er_of _packe t s + i; 

size_ptr= addr(receive_dat a_'bl ock . frame _ler.g th_l sd ) ; 
if (size > 1522 I size < 64) then 
do ; 

put skip list('SIZZ 3RR0R'); 
stop; 
end ; 

source = '00'b4; 

If ( recei ve_data_hlock . source_addres s_f = vax) then 
do ; 

source = vax; 
do i = 1 t'o 4; 

seg_ack(i) =receive_data_hlock.data ,i + 24) 
end ; 
end ; 

r9c_hlk_ptr = adir ' recei ve_da ta_ o lock . da ta ( s i ze-4 ) ) ; 
copy_ie_regis t er = recei ve_hlock_availaole ; 
call wr ite_io_port 'interrupt_enatle_register, 

recei ve_block_ava liable); 

end; /* if receive dma done 



else 

if (copy_ie_regis ter = t ransmi t_dma_done ) 
then do; 

copy_ie_register = receive_block_ava liable; 
call write_io_port 'interrupt_er.able_register, 

recei ve_block_ava liable); 

end; if transmit dma done */ 



end HL_interrupt_handler ; 
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r- 



• 






This 



:he 



9T;o‘:?_losin -oduie. 
the TC? header. Since 
pended to the 



he 

C? 



in IS nod'jle is called from 
calculates the chec>sun for 

calculation involves a^^pseudo header prepended to 
header, the variatls "temp’* stores all the bytes of merory 
located Just nrior to the TC? header (that it, the last 12 
bytes of the IP header). Overlays are used that bit(S) 
values can be used as integer values without ^suffer ing from 
conversion factors. The variable ”int_length* is the length 
cf the IP dtatgram and therefore includes the TCP segment. 
The variable "seg_len’’ is the length of the TC? segment. If 
the length of the segment is an odd number, then an extra 
null byte is added so that there are full 16 bit words for 
the checksum calculation. NOTE: the divide function is 

it returns the floor value should there be a 



used ; 

remainder from the division. 



V 



calc_tcp_cksum : 



procedure ; 



del 

cksum entry (bit (8) .fixed bin ( 7 ) , bi t ( 16 ) ) , 
f ixed_overlay bit(B) based ( fi xed_overlay_ptr ) , 

fixed_overlay_ptr pointer, 

int_length fixed bin(7) based ( i nt_leng th_p t r ) , 

in t _length_pt r pointer, 

numl6bit_wds fixed bin(7), 

odd bit(l), odd IP length 

temp( 13 ) bit (S ) » 



odd = false; 

do i = 1 to 12; /=!* save last 12 bytes of I? header ’•'/ 

temp(i) = transmi t_data_block .da ta ( i + £); 

end ; 



/- form tep PSEUDO HSADEP. =>-/ 



transmit_data_block.data(9) 

transmit_data_block.data(10) 

transmit_data_block.data(ll) 

transmit,_data_block.data(12) 

transmit_data_block.data(13) 

transmit_data~block.data(14:) 

transmit_data_block.data(l5) 

transmit_data_b lock. data (16) 

transmit~data_block.data(17) 

transmit_data_block.data(18) 

transmit_data_block.data(19) 



'c0'b4; 
'09'b4; 
'cB'b4; 
'01 'b4; 
'c£'b4; 
'09'b4; 
'c3'b4; 
'03 'b4; 
'00 'b4; 
'06'b4; 
'00'b4; 
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/■>!■ overlay tit(S) with fixed value 
irit_length. ptr = addr (ir.terr.e* _header .lerigth_l 5 b ) ; 
5es_len = rir.t_len.?:d - 22''; 
numl6cit_wds = divide( (ini_length - 3), 2,?); 

/•^ cdeck: if ien^th^^is odd nunber of bytes 
if ( nod { seg_len ,2 ) "= 0 ) then 
do ; 

odd = true; 

numlobi t _wds = nurnl6bi t_wds + 11 

temp(13) = transnit_data_block.data ( int_length f-l); 
transmit_data_block: .data (int_length +1) = '00'b^; 
end; 

insert byte 12 of pseudo header ’*'/ 
fixed_overlay_ptr = addr ( seg_len ) ; 
tran smi t_d a ta_block .da ta ( 20 ) = f ixed_overlay ; 

call cicsun( transmi t_data_block .data (9 ) , 

nurnl6b i t_wd s , tcp_header .checksum ) ; 

/■ir- fsstcre I? '■'? 
do i = 1 to 12; 

transmit_data_block.data ( i + 8) = temp(i); 

end ; 

if odd = true then 

transmit_data_block.data ( int_length +1) = tenp(13); 



end calc_ t c p_cksun ; 



/ 



nr -r* 



0 wL » ^0 %t0 ^0 ^X0 %*0 ^^0 ^0 %^0 y 

« ^1% ^1% • I #1% ^1% 0(^ ^1^ #p 0^% 0f ^p /p Vp ^p Vp «p ^p ^p #p #p #p ^P / 



This module 
es talishment 



sends the packets necessary for the connection 
to the VAX and the remote login protocol up to 



the point where the VAX asks for Password 



lach packet 



update c ha ages only those portions of the packet that are 
different from one packet to the next. There is no 
processing of inbound packets except for VAX seauence 
numbers and data to be pushed. It assumes no deviation from 
a normal login seaunece. 



»V V* ♦.'i* •*'* **» V** '’** 

^ ^ ^ ^ 



«r mm ^ -I' " 



# « 



’ 3^ 3jS 5jS 3jS 5{t a{C ; 



3r 3|i J}C 3jS 



mm n'-mm •- 



V 



remo te_l ogi n : procedure; 

declare 

source bit(6) external, 
packe t_length fixed bin(7) external, 
add 32 bit entry (bit(9),bit(S),bit(8)), 
cksum entry ( bi t ( 3) , f ixed b i n ( 7 ) , b i t ( 16 ) ) , 
write_io_port entry (bit '8) ,bit (8) ), 
numiebit vds fixed bin(7) external; 
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/* send packet 1 
nij'Til6'bi t_vds = 13 

call cx suTi ( in te rnet_head e r . vers i on_i hi .numlcti i t _vds , 

interr.et_header . hdr_checksu.'n ) 
call calc_tcp_cl-csu.'n* 

Dacket_ler.sth = 46 » 

call transmit_packet(packet_len^th); 



/'' assume V iX wi ll_acknowledae it #1, wait until it does '^ / 

do while { source ~= vax ) .* 

end; 



/* packet _2 update *^Z 
inc_sea_num (4 ) = '31'b4; 

call add32'bi t ' tcp_header . s equence num ( 4 ) , inc_sea _num 4 ) , 
tcp_header . sequence _num (4T) ; 
tcp_header . of f set = '50'o4; 
tcp_header . cont rol = ack; 

call add32bit :'seg_ack(4) ,inc_seo num ( 4 ) , tcp_heade r .ack_num (4 ) ) ; 
internet_header .iength_lsb = 'ZS'^bd; 
internet header. id Isb = '02'b4; 



/* end packet_2 update 
numl6bi t_wds = 10; 

internet_header .hdr_checksum= '0Z00'b4; 

call cksum(internet_header.version_ihl, numlSbi t_wds , 

internet_header.hdr_ checksum) ; 
tcp_header . checksum = '0000 'b4; 
call calc_t cp_cksum ; 
packet_length"’= 46; 
call transmit_packet(packet_length); 



packet 3 update 

internet_heaier . length_l sb = '29 'b4; 
tcp_header .control = ack psh* 
tcp_header .data ■ 1 ) = '00*^b4; 
tcp_header .da ta ( 2 ) = '04'b4; 
tcp_header .da ta I 3) = '04'b4; 
tcp_header .data(4) = '00'b4; 
tcp_header .da ta ( 5 ) = '00'b4; 
tcp header .da ta ( 6 ) = '00'b4; 
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03 'c4:; 



i n t e r ne t _I:ie ad 9 r . id_l s 3 = 
r.uTil 5tii t _wd s = 10 ** 
i r. t e r ne t _h9 ad er . hd r_c a 9c ksum = 

call cksum ( in; 9rn9 1 _li9ad9r . V9rs i on_i£il , numiedi i_wds , 

in 1 9rn9t _h9adar . hdr_ch.9cks’jm ) ; 
t cp_h9ad9r . chacksun = '0000''b4? 

call calc_tcp_cksum ; 
pack9t_l9.ngta = 46? 

call transmit_pack9t(pack9t_l9ngth); 



/* packat 4 updata ‘^/ 

in ta rna t_haadar . length_l St = '2a 'b4; 
inc_s eq _num '4 )= '01 't4? 

call add32tit(tcp_haadar.saauance_num(4) ,ir.c_saq_num(4) , 

tcp_haadar . saauenca_nurri(4 ) ) ? 

tcp_haadar ,da ta ■' 1 ) = '72't4? 
tcp_header .data (2 ) = '65't4? 
t cp_haade r . da ta ( 3 ) = '65't4; 
tcp_haader .da ta (4 ) = '6t't4; 
tcp_haadar . da ta (5 ) = '65 'b4; 
tcp_haadar . da ta ( 6 ) = '00'b4? 

i n ta rna t_haadar . id_lsb = '04'b4? 
numl6bit_wds =10? 

in t arna t_haada r .hdr_chacksurn = '0000'b4? 

call cksum( intarnat_haadar .varsion_ihl ,numl 6bi t_wds , 

intern9t_headar . hdr_checksu,’Ti) ? 
tcp_haadar .chacksum = '0000'b4? 
call calc_tcp_cksun? 
packat_langth = 46? 

call transmit_packat (packet_langth)? 



/* sagmant 5 updata */ 
inc_seq _num (4 )= '06't4? 

call add32bit ( tcp_haadar . secuence_nun(4) . inc_seq _num (4) , 

tcp_headar . sequanca_num (4 ) ) ? 
i n ta rna t_haad ar . id_lsb = '05'b4? 
numloti t_vds = 10? 

intarnat_header .hdr_chacksum = '0000 'b4? 

call cksum(intarnet_haadar.varsion_ihl,numl6bit_vds, 

intarnat_haadar . hdr_chacksurri ) ? 
tcp_haadar . chacksum = '000C'b4? 
call cal c_tcp_cksum ; 
packat_length = 46? 

call transmit_packet(packat_langth ) ? 
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/* packet 6 update */ 



internet_header.ler.gtt_ls'b ='31 '1)4: 
i ac_seq_n'am '4 ) = '06 'b4 ; 

call add32tit (tcp_header.seauence_nu'^(4) ,iac_sea_nu-n(4) , 

tcp head er . seauence_num (4 ) ) i 
internet header . id' Ish ='05'h4: 



tcp_header.data(l) 
tcp_header . da ta (2 ) 
tcp_header . da ta (3 ) 
tcp_header .da ta ( 4 ) 
tcp_header . da ta ( 5 ) 
tcp_header.data(6) 
tcp~header .da ta (7 ) 
tcp_header . da ta ( 8 ) 
tcp_header . da ta (9 ) 



='73'h4; 
='75'b4; 
='6e'h4; 
= '2f "b4; 
='39'h4; 
='36'b4; 
='30'b4; 
='30'b4; 
= '00 'b4; 



numl6bit_wds = 10J 

interne t_header .hdr_checksum = '0000 'b4J 

call cksum( internet_header .version_ihl,nurnl5bit_wds, 

int ern et _header .hdr_checksum ) ; 
tcp_header . checksum = '0000'b4I 
call calc_tcp_cksum; 
packet_length = 49? 

call transinit_packet(packet_len^th); 



/* wait unti vax replies 

do while ^source ~= vax); 
end; 



/* wait until vax replies with its null byte */ 

do while ( (source = vax) S. 

( receive_da ta_bl ock .da ta (34 ) ~= ack_psh) ); 

end ; 



/'^ packet 7 undate */ 

interne t_header . length_l sb = '2S'b4; 
inc_sea_num (4 )= '09 'b4; 

call add32bit( t cp_header .seauence_num(4) ,inc_seq_num(4) , 

tc p_head er .seouence_num(4)); 
inc_seq_num (4 )= '01 'b4; 

call add32bit(tcp_header . ack_num (4 ) , inc_seo_num ( 4 ) , 

tcp_header .ack_num(4 ) ) ; 
tcp_header . control = ack; 
internet header. id Isb ='07'b4; 
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tcp_header . da ta ( 1 ) ='2f'b4; 
t c?_hsader . da ta f 2 ) ='39'b4J 
tcp_head8 r . da ta ^ 3 ) ='36'b4? 
tc p_header . da ta . 4 ) ='33'b45 
t cp_header . da *a ( 5 ) ='30'b4J 
tc p_header . da ta . 6 ) ='00'b45 

r.uml6bi t_wds = 105 

internet~header .hdr_chec'jcsum = '0000'b45 

call cks urn ( internet _header.versi on _i hi, nutnl 6b it_wds, 

internet_header .hdr_checksam ) ; 
tcp_header . checksum = '0300 'b4; 
call calc_tcp_cksum; 
packet_length = 465 

call transmit_packet(packet_length); 



put skip list ('PACKET SENT'); 
put skip; 

do while ( number_of _packets < user_desires ); 
end; do while 



end remo te_logi n ; 



end ; 



APPENDIX E 



SOURCE CODE FOR 32 BIT ADDITION 
EXAMPLE OF CALL TO THIS PROCEDURE 

call add32bi t ( numberl ( A ) , number2( 4 ) , r esult ( 4 ) ) where: 

parameter 1 is the least significant byte of a 
32bit number (array cf 4 bytes) 
parameter 2 is the Isb of another 32 bit nu-^ber 
parameter 3 is the Isb of the result 



The 32 bit numbers are stored in memory such that the his'' 
order byte occupies the lowest memory location. This is 
contrary to the way that PLl stores numbers. The numbers 
are stored in this manner because they have been DMA'd 
into memory by the NI3010 board in the order they were 
recieved over the Ethernet, i.e., high order byte 
recieved first. 

The algorithm adds the numbers byte by byte starting with 
the low order bytes and places the rseultant byte addition 
into the corresponding result byte position. 



public add32bit 



add32bi t : 



cseg 
push ax 


! push bx! 


push cx! push dx ! push 


si ! push 


di ! 


mo V 


ci , 04h 


; number of bytes 


to be added 


mo V 


si , [bx] 


; ( 32 bi t number ) 

;ioad index registers with 


address 


mo V 


di ,2[bx] 


;the Isb of each 


number to 


be added 


mo V 


dx , 4 [bxl 


^pointer to the 


Isb of the 


result 


clc 
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■bes : 
fno V 


al , [si^ 


• byte 


of first number to add 


mo V 


ah , Ldi] 


J b y t e 


of other number to add 


adc 


ah , al 






dec 


si 


^decrement pointer and store 


push 


si 






mo V 


s i , di 


; make 


si now point to result 


mo V 


[si] ,ah 


»move 


addintion into result 


dec 


si 


; 5 tep 


down in memory 


mov 


di ,si 


; save 


pointer to result 


pop 


si 






dec 


di 






loop 


beg 






pop di ! 


pop si! pop dx ! 


pop cx 


! pop bx ! pop ax! 


re t 









t dway 
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ipPENDIX F 



CHECKSUM PROGRAMMING NOTES AND SOURCE CODE 
The checksum algorithm for the IP header and the TCP 
segment are the same. The official specification for the 
algorithm is: 

The Checksum field is the 16 hit one's complement of 
the one's complement sum of all 16 hit words; for 
purposes of computing the checksum, the checksum 
field is zero. [Ref. 3] 

Another source lists the alsorithm as: 

The checksum field is to simply add up all the data 
regarded as 16 hit words, and then to take the one's 
complement of the sum. [Ref. 6] 

The assemhly language program helow always agreed with the 
checksum calculations that were contained in the packets. 
Initial attempts yielded inconsistent reults when compared 
to those in the UNIX produced packets. Some attempts always 
produced the correct result for the IP header and 9?% of the 
time for the TCP header. Other attempts were less 

consistanr than the above example. Since one's complement 
arithmetic is used, the erroneous implementations can 
produce results that are auite close to those produced hy 
the UNIX operating system. 

The program helow implements the algorithm as if the 16 
hit words were integers stored with the least significant 
hyte in low memory, followed hy the most significant hyte. 
Note that the first hyte of the word is loaded into the low 
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side of the 15 hit registers in the 80S6 micro-processor and 

the second hyte loaded into the high side of the registers. 

;EX1^^?LE 0? CALL TO THIS PROCEDURE 
;call cksum(i,y,z) where: 

I 

; parameterl (hit (8)) is the starting hyte of data 

; to he summed 

; parameter2 (fixed bin 7) is one-half the length of 

; the block (# of 15 hit words) 

; parameters (hit(16)) the resultant 16 hit checksum 

• 

IThe dx register will contain the resultant checksum. 



public cksum 



cksum : 



cseg 



push 


ax! push hx ! 


push cx! push dx ! push si! 


mov 


si ,2[hx] 


;ioad cx with one-half the length 


mov 


cx , [si] 


mov 


ch , 00 h 


; zero out high side of cx register 


no V 


dx , 0000h 


Jzero out running total of checksum 


no V 
clc 


si , [hx] 


;si points to first hyte of block 



a^ai n : 








mov 


al , [si] 


Imsh 


of 16 hit word 


inc 


si 






mov 


ah, [s i] 


;ish 


of 16 hit word 


adc 


dx , ax 


; add 


to running total 


inc 


si 






loop 


again 






lor 


dx , 0f fffh 


;i's 


complement of running total 


mov 


si ,4 [hx] 


Iplace result in return parameter 


mov 


[si] ,dl 






inc 


si 
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mo V 



[si] ,dh 

pop si! pop di ! pop ci! pop tx ! pop ax 
ret 
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APPENDIX G 



INCLUDE FILE FOR PROGRAM LISTEN 



^replace 

I/O port addresses 

These values are soecific to the use of the INTSRLAM 
NI301^ MULTIBUS to ETHERNET interface hoard. Any 
change to the I/O port address of '0?h0' hex (done 
so with a DIP switch) will reouire a change to 
these addresses to reflect that change. 






command_register 

command_status_register 

transmit_data_register 

interrunt_status_reg 

interrupt_er.ahle_register 

high_hy te_coun t_r eg 

low_hyt e_count_reg 



by 


'b0 


'b4, 


by 


'bl 


'b4, 


Ly 


'b2 


'b4. 


by 


'be 


'b4, 


by 


'b8 


'b4. 


by 


'be 


'b4, 


by 


'bd 


'b4, 



/* end of I/O port addresses =>•/ 



/ 



Interrupt enable status regis 
disable_ni3010_interrupts 
ni3010_intrpts_disabled 
receive _b lock _available 
transmi t_drria_done 
receive d-na done 



ter values ^/ 
by ^00^b4, 
by '00'b4, 
by '04^b4, 
by '06'b4, 
by "07'b4, 



/* end register values */ 

/'^ Command Function Codes */ 



module_interface_l OOP back 


by 


'01 ■ 


'b4, 


inter nal_locpback 


by 


'02' 


'b4, 


clear_l oopback 


by 


'03' 


'b4, 


go_off 1 ine 


by 


'08' 


'b4. 


go_online 


by 


'09' 


'b4. 


onboard _dia gnostic 


by 


'0a ' 


'b4, 


load transmit data 


by 


'28' 


'b4, 
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load_ar.d_ser.d 
rese t 

se t_proTii sc vous_mode 
clear insert source address 



by '29 'b4, 
by '3f'b4, 
by '04 'b4, 
by '0e'b4; 



/* end Command function Codes */ 
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APPENDIX 5 



INCLUDE PILE EOF. PFOGRA^' DEf^O 



dec la re 

1 internet_header based ( in t_hdr_p tr ) , 



2 


versi on_ihl 


bit(8) . 


2 


type_of _service 


bit(8) , 


2 


1 ength_msb 


b i t ( 8 ) , 


2 


length_lsb 


bit(S) , 


2 


i d_ms b 


bit(3) , 


2 


id_lsb 


b it ( 8 K 
bit ( 16) . 


2 


f lags_f rag 


2 


t tl 


bit (3) , 


2 


pro tocol 


b i t ( 3 ) . 


2 


hdr _checlcsum 


bit (16) , 


2 


s ourc8_a 


Dit (3) , 


2 


source_b 


bit(8) . 


2 


s our ce_c 


bit(3) , 


2 


s ource_d 


bit(3) , 


2 


des t _a 


bit(3) . 


2 


des t _b 


bit(8) , 


2 


des t_c 


bit (3) , 


2 


des t _d 


bit (8 ) , 


1 


tcp_header based(tcp 


hdr ptr) 


2 


source_port 


bitTie) . 


2 


des t_por t 


bit (16 ) . 


2 


sequence_num(4 ) 


b i t ( 3 ) . 


2 


aclc_num(4) 


bit (3) , 


2 


offset 


bit(S) , 


2 


control 


bit(S) , 


2 


V indow_msb 


bit(3) , 


2 


window_l sb 


bit (3) , 
bit(16) , 


2 


che cksum 


2 


urgent_pointer 


bit(16) . 


2 


data ( 512) 


bit(8) . 


int. 


_hdr_ptr pointer 


9 


tcp^ 

seg' 


_hdr_ptr pointer , 

_len fixed bin (7 ) , 
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These 4 element arrays are 32 tit variatles 









inc_sea num(4) tit(S), 
se^ ackr4 ) ti t ( 8 ) ; 



%replace 

/* Control tit 
ack 

ack_psh 

syn 

ack_fin 

ack_syn 



for the TCP header */ 

ty "0001?3f'2't , 
ty '00011000 't, 
ty '00000010 't, 
ty '00010001't, 
ty '00010010 't, 



/* I/O port addresses 

These values are specific to the use of the IMT3P.LAN NI3010 
MULTIBQS to ZTHERNBT interface hoard. Any change to the I/O 
port address of '^0t0 ' hex (done so with a DIP switch) will 
require a change to these addresses to reflect that 
change . 



command_regis t er 


by 


't0 'b4, 


command_s tatus_regi ster 


by 


'tl 't4, 


transmi t_data_ register 


by 


't2't4, 


i n terrupt _s ta tus_reg 


by 


't5't4, 


interrupt _enable_ re gis ter 


by 


'ta't4 , 


high_ty te_count_reg 


by 


'tc 'b4, 


low_byte_count_reg 


by 


'td 't4, 



/* end of I/O port addresses 



/* Interrupt enable status register values */ 



disable _n 1301 0_ interrupts 
ni3010_intrpts_disatled 
receive_tlock_ava liable 
transmi t_dma_d one 
receive_dma_done 

/* end register values */ 



ty '00't4, 
ty '00't4, 
ty '04't4, 
ty '06't4, 
ty '07't4, 
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Command Fun r* ion Codes / 



/- 



module_interface_loopbac'£ 


by 


'01 


;b4, 


internal_loopbac'K 


by 


'02 


b4. 


clear_l oop back 


by 


'03 


'b4, 


go_of fl ine 


by 


'08 


'b4, 


go_online 


by 


'09 


'b4, 


onboard _dia gnostic 


by 


'0a 


'b4. 


load_transmi t_data 


by 


'28 


;b4. 


load_and_send 


by 


'29 


M, 


reset 


by 


'3f 


'b4. 


set_promiscuous_mode 


by 


'04 


>4, 


clear_insert_source_address 


by 


'0e 


b4; 


end Command Function Codes 


-T* 


/ 
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